issue with a non USA IP getting added to North America IPV4 List

igoldstein

Hi

when I check the "pfB_NAmerica_V4" Table, I see it has an entry of "20.199.0.0/17"
the IP is a non USA IP

why is the IP considered as a North America IP ?

when i opened a ticket with MaxMind which I assume is where pfblocker gets the data from, and below is their response

=========

Thank you for contacting support. Using our GeoIP2 database demo at https://www.maxmind.com/en/geoip-demo, I'm seeing that we currently do locate 20.199.0.0/17 to France; however, we also return the United States as the "registered_country" output.

In contrast to the "country" output (which locates end-users), the "registered_country" output indicates the country where the IP is registered by the ISP. This often does match the end-user country, but not necessarily, as IP addresses may be registered in one country but have end-users located in another.

If you have updated to the current release of our database but are still seeing United States returned as the end-user geolocation, you may wish to review your integration to ensure that you are using the "country" output as intended, rather than the "registered_country" output.

Kind regards,

michmoor

@igoldstein 20.192.0.0/10 is administratd by ARIN which is a North American Internet Registry.The block is owned by Microsoft. Because they own the range, they can chop up that address(which they clearly did) and advertise it wherever they want and in this case the /17 is out of France as you say.
PFB is pulling data from bgpview so I'm guessing, based on the fact ARIN deals with NorthAmerica allocation, pfb bases its logic on that.

@bmeeks is the maintainer so he would have a clearer answer.

johnpoz

@igoldstein nobody ever said maxmind was perfect - lets get that right, they have loads of issues with their db. I can tell you that from personal experience, and getting it changed is near impossible.

We had a block of IPs out of /16 registered with Arin, had it forever. Then they started saying a /24 out of that was coming out of Vietnam. It was causing users of the proxy, that was out of FL from accessing their bank account web sites.

I tried for months to get it resolved - fell on death ears, they don't tell you when they run their updates like every 2nd tuesday of the month if they accepted your submission or not, or denied because of xyz or anything.

IP space is fluid, it moves all the time, as more and more people bid over the limited space it could end up anywhere on the planet as you sell off or move blocks to even a different registry - we sold off like half of that /16 that I know for sure went to go be used under ripe vs arin, since I was part of the transfer process, etc.

While with a wide brush they are mostly accurate from what region of the world an IP is from, there is always going to be one offs and mistakes, etc.. It is almost impossible to keep such a db true, especially with all the movement of ips of late. What they need to do is make their correction process better.. And be more responsive to owners of IP space wanting to actually validate where its coming from, and willing to provide whatever documentation/proof of where its being used.

I mean really they were saying a our IP was coming out of vietnam, when a simple ping from anywhere in the us would tell you it sure and the hell was not in vietnam from the response time. Let a long a simple traceroute showing you all the ips used to get there, etc. ;)

If you couldn't tell, not a huge fan of maxmind and their support ;) hehehe

edit: even without an IP that answers ping, can tell you its not in the us, look at these hops

  9    15 ms    15 ms    13 ms  ae35-0.icr01.ch4.ntwk.msn.net [104.44.237.19]
 10   109 ms   109 ms   112 ms  be-120-0.ibr02.ch4.ntwk.msn.net [104.44.11.22]
 11   108 ms   109 ms   110 ms  be-11-0.ibr02.cle30.ntwk.msn.net [104.44.29.44]
 12   109 ms   109 ms   109 ms  be-10-0.ibr02.ewr30.ntwk.msn.net [104.44.17.216]
 13   109 ms   109 ms   109 ms  be-3-0.ibr02.nyc30.ntwk.msn.net [104.44.7.104]
 14   111 ms   111 ms   110 ms  be-7-0.ibr02.lon22.ntwk.msn.net [104.44.18.155]
 15   109 ms   109 ms   109 ms  be-1-0.ibr02.lon24.ntwk.msn.net [104.44.16.56]
 16   110 ms   109 ms   186 ms  be-5-0.ibr02.par21.ntwk.msn.net [104.44.29.34]
 17   117 ms   118 ms   110 ms  ae124-0.icr03.par21.ntwk.msn.net [104.44.23.143]

You can see by the hops answering and the response time - nyc, most likely new york city, and then london, and most likely paris..

igoldstein

i understand that an IP block can be further chopped up,

you can take a chunk IP block from a bigger chunk block that's used and registered in FRA, and the smaller chunk will be used in USA

or vice versa,
you can take a smaller chunk of IP from a USA block, and use it in FRA

how should I handle my firewall rules if i want to truly only allow USA IP's ?

johnpoz

@igoldstein said in issue with a non USA IP getting added to North America IPV4 List:

how should I handle my firewall rules if i want to truly only allow USA IP's ?

Compile your own list ;) if you can not trust the maxmind one.. Curious how did you find out this 20.199 IP was not us?

Gertjan

@igoldstein said in issue with a non USA IP getting added to North America IPV4 List:

how should I handle my firewall rules if i want to truly only allow USA IP's ?

Short answer : you can't be sure these days.
Most of the known 'big' networks don't change, stay in place, but small segments are transferred, as IPv4 are big mone, it is a resource rather expensive.

I wonder how things will works out with IPv6 ....

keyser

@gertjan said in issue with a non USA IP getting added to North America IPV4 List:

@igoldstein said in issue with a non USA IP getting added to North America IPV4 List:

how should I handle my firewall rules if i want to truly only allow USA IP's ?

Short answer : you can't be sure these days.
Most of the known 'big' networks don't change, stay in place, but small segments are transferred, as IPv4 are big mone, it is a resource rather expensive.

I wonder how things will works out with IPv6 ....

It will likely be way way worse over time :-)

I’m starting to think IPv6 will fail to take over the Internet. The standards are still HUGELY open for interpretation, and interoperability between systems are rather random still (And we are some 15 years down the line now). Even basic stuff like Slaac and RA is flaky with many ISPs, and lets not even get started with DHCPv6, DHCPv6-PD and DHCP Options. Most OSes doesn’t work with this unless you start doing some serious geeking and customizations to get basic stuff going - A few can’t even be brought to a working state.

Meanwhile IPv4 NAT ingenuity has reached new levels, and proved that it can scale - allthough not easily - to handle the never ending growth.

Gertjan

@keyser said in issue with a non USA IP getting added to North America IPV4 List:

The standards are still HUGELY open for interpretation

Ah, lol, just check the recent "my (IPv4) NAT rule doesn't work" forum posts.
Why to NAT (PAT) and how to NAT (PAT) has been crystallized (RFC'd ?) out and needs the same manipulations on any router these days.
Still, people make something else of it. pfSEnse uses a GUI ... now even more poeple think that got it.
Wrong ...

IPv4 has to die. It's like a 6 digit phone number system back in the old days.
Wasn't can't be 6 billion on earth with 2^32 IPv4, as no one can tell these future Phone owners that they will live in an IPv6 only worlds, and only some of use have native IPv4. Or build even more complex systems that tunnel IPv4 over IPv6. Or build some massive 'global' NAT system, as phones tend to roam around.

The back bone is totally ready.
The root DNS and TLD DNS is ready.
The wires are ready ;)
Some ISP make a mess out of it, true. I'm using one myself that just now (nearly end of 2022) that end users should have Ipv6 and not only one /64 (they reserve a /56 for a client/user but only make a /64 usefull - so you can say IPv6 works, but not behind pfSense).

I'm using tunnel.he.net for years now.
These days, I can even visit the site of my ISP, www.orange.fr using Ipv6 with seeing huge glicthes
Netflix works now (they thought I was using some sort of VPN, technically they were not wrong)
My own sites are IPv6 ready for years now.
My mails on my own postfix server, for all my domains, have one IPv4 and one IPv6, most mail traffic is actually IPv6 these days. Big players are all initiating IPv6 and fall back to IPv4 if needed.

I'm visiting and posting on forum.netgate.com using IPv6 for years now :

Most of my internal networks are working fine with IPv6 and using it. they are still some legacy IPv4 device, but I don't mind. I can handle my own IPv4 even if the net abandoned it, most of the legacy device don't need an Internet connection anyway.

@keyser said in issue with a non USA IP getting added to North America IPV4 List:

(And we are some 15 years down the line now)

I know. I remember the IPv6 day way back. I was also thinking : we'll tackle that one in a year or so. But it start to look like the fusion solution : it will happen in the next 10 years.

Oh, yeah : my Synology diskstation IPv6 : 2001:470:1f13:5c0:2::c2 and this is not some RFC1918 like IP, this one works on planet (solar system) level.
So now my firewall will get tested ;)
Knowing that many will hide their RFC1918

And what the heck : even the reverse works !! (I'll leave it up to you to discover it )

@keyser said in issue with a non USA IP getting added to North America IPV4 List:

like Slaac

Will get shot, like Clippy.

@keyser said in issue with a non USA IP getting added to North America IPV4 List:

DHCPv6, DHCPv6-PD

What's wrong with those ?
I'm an old guy, so when I get my static IPv6 /48 (I've one) I like to carve out a /64 for each physical network, and then assign 'static' known IPv6 using a DUID.
Why do you think my diskstation always has the same IPv6 ?
And when the system dies, I'll give that IPv6 to the new NAS.
( like I'm not trusting my own DNS ;) )

@keyser said in issue with a non USA IP getting added to North America IPV4 List:

Most OSes doesn’t work with this unless

Are you sure ? Windows, MAC OS, Linux, FreeBSD are fine for me.
( noop, I've never touched an android device )
I do not touch any - my - OS network settings on any device, NAS and printers included.
I select "activate IPv6" allthough its already on these days.
I prepare my IPv6 DUID static lease on pfSense.
Done.
Like in the old days.

Anyway, When eIPv4 is working and IPv6 is working, I feel ready.

NogBadTheBad

It's a Microsoft IP address range:-

AS details for 20.199.0.1 :-

route:      20.192.0.0/10
descr:      Microsoft
origin:     AS8075
notify:     radb@microsoft.com
mnt-by:     MAINT-AS8075
changed:    mkasten@microsoft.com 20200721
source:     RADB

route:      20.0.0.0/8
descr:      REACH (Customer Route)
tech-c:     RRNOC1-REACH
origin:     AS17916
remarks:    This auto-generated route object was created
remarks:    for a REACH customer route
remarks:    
remarks:    This route object was created because
remarks:    some REACH peers filter based on these objects
remarks:    and this route may be rejected
remarks:    if this object is not created.
remarks:    
remarks:    Please contact irr@team.telstra.com if you have any
remarks:    questions regarding this object.
notify:     irr@team.telstra.com
mnt-by:     MAINT-REACH-NOC
changed:    irr@team.telstra.com 20090917
source:     REACH

bmeeks

@michmoor said in issue with a non USA IP getting added to North America IPV4 List:

@bmeeks is the maintainer so he would have a clearer answer.

No, I have nothing at all to do with pfBlockerNG nor pfBlockerNG-devel. The volunteer maintainer for that is @BBcan177.

I look after only the Snort and Suricata packages.

michmoor

@bmeeks you're right my apologies. To many 'B's :)

igoldstein

@nogbadthebad said in issue with a non USA IP getting added to North America IPV4 List:

It's a Microsoft IP address range

and in what country are the IPs used ?

if its an IP used outside of USA, I don't want it to pass the gate.

Gertjan

@igoldstein
Because Microsoft owned IPs try to connect to you ?

michmoor

@igoldstein what are you trying to prevent? GeoIP blocking is hard enough as it is as you can see. The best you can do is using a high quality IP block list.

igoldstein

@michmoor said in issue with a non USA IP getting added to North America IPV4 List:

The best you can do is using a high quality IP block list.

any setups you can suggest? i currently use pfblocker package which i believe utilizes maxmind

@michmoor said in issue with a non USA IP getting added to North America IPV4 List:

what are you trying to prevent?

currently I have a rules that allows any USA IP, and block everything else

michmoor

@igoldstein As we suggested already IPs aren't necessarily bound to their geographic location. Blocking IPs based on a location is not highly accurate for the reasons listed above. The IP block lists that come with PFblockerNG are good enough if you want to craft a GeoIP rule around it.
If you have no services/applications exposed to the internet than this is a non-issue.
If you do have services/applications exposed to the intenret than IP blocking is fine.

igoldstein

i do have services exposed to the internet
hence why i want to allow ONLY USA IP's

IPs that are used in USA, not just Registered in USA

johnpoz

@igoldstein said in issue with a non USA IP getting added to North America IPV4 List:

IPs that are used in USA, not just Registered in USA

Good luck finding that list... Not sure how many times this needs to be said, there is no such list. There will always be mistakes, IPs move all the time. I could route a network out of Dallas today, and Paris tomorrow..

Your best solution is IPs you find that are not coming from the US put in your own block list, and put this top your rules order. Before you allow of the US IP list.

Still curious how you found this IP was not coming from the US. Did you go through the complete list of networks in the US list?

edit: https://support.maxmind.com/hc/en-us/articles/4407630607131-Geolocation-Accuracy
"It is not possible for us to guarantee 100% geolocation accuracy. Accuracy exhibits high variability according to country, distance, type of IP (cellular vs. broadband, IPv4 vs. IPv6), and practices of ISPs."