issue with a non USA IP getting added to North America IPV4 List
-
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 FRAhow should I handle my firewall rules if i want to truly only allow USA IP's ?
-
@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?
-
@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 ....
-
@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.
-
@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.
-
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 -
@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.
-
@bmeeks you're right my apologies. To many 'B's :)
-
@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.
-
@igoldstein
Because Microsoft owned IPs try to connect to you ? -
@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.
-
@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
-
@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. -
i do have services exposed to the internet
hence why i want to allow ONLY USA IP'sIPs that are used in USA, not just Registered in USA
-
@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."
