Kibana Add filter should use LTE not LT on IP fields

[spartan782]

Kibana version:
7.4
Elasticsearch version:
7.4
Server OS version:
N/A
Browser version:
N/A
Browser OS version:
N/A
Original install method (e.g. download page, yum, from source, etc.):
N/A
Describe the bug:
When using the add filter in Kibana to create a filter for IP address (or any data) using the is between it applies a GTE to the start but a LT to the end. This creates unexpected results especially when doing network blocks because you still see all of the broadcast or don't see them depending on how you applied the filter.

Steps to reproduce:

1. Have data set with 2 distinct IP ranges in it and that follows ECS or some standard that shows Server (Originating) and Client (Responding). In my data set I have a lot of public IP's and my test environment 172.16.100.x/24
2. Apply a filter for server.ip is between 172.16.100.0 to 172.16.100.255
3. Apply a second filter for client.ip is NOT between 172.16.100.0 to 172.16.100.255

Expected behavior:
You only see Server IP's from your range talking to anything other than your servers. In my case I should see all of my test network talking to Public IP's. That is not the case though.

Screenshots (if relevant):
I crafted a query and filter to show the miss-leading results. Here is a screen shot of the 36 hits I get back that would normally get lost or overlooked in the millions of events.

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:
Here is the kibana query for more context. I think the easiest solution for any analyst not just in the security or IP space would be to include on both ends not just the beginning. Removes bad filter results and is easy enough and intuitive enough to understand that it is using an include on the last entry added.

Kibana_query.txt

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

@Bargs @TinaHeiligers I am a bit on the fence regarding this topic. I would agree that a "between" on IP fields feels more natively including the upper bound. But then it would behave a bit differently than on numeric fields where (and I think it's what it should be) the upper limit is exclusive, and having unaligned behavior might also be confusing in the end? What's your opinion on this?

[Bargs]

Maybe it would be best to leave the range query as-is for consistency, but add support for CIDR notation in the regular match filter, which we currently have an issue for?

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.