Perhaps I'm double NATing?
-
Thanks for the note Steve. The response time for that hop is 7 ms. Time to my pfSense firewall is <1 ms, which is what I would expect. I think tomorrow I'll remove the switch from the path and patch the PC directly to the modem. That would isolate everything else in the house and I'll run tracert again.
-
@mvmatch 7ms is definitely external if we're talking wired connections. Now that I'm near a PC, if I search I see at least one post about Comcast using it in 2018.
https://en.wikipedia.org/wiki/Carrier-grade_NAT
-
The 3rd address looks like it’s allocated to the Air Force, unless they’ve sold some of their address space.
ARIN WHOIS data and services are subject to the Terms of Use
available at: https://www.arin.net/resources/registry/whois/tou/
If you see inaccuracies in the results, please report at
https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
Copyright 1997-2022, American Registry for Internet Numbers, Ltd.
NetRange: 162.24.0.0 - 162.24.255.255
CIDR: 162.24.0.0/16
NetName: BOLLING-LAN
NetHandle: NET-162-24-0-0-1
Parent: NET162 (NET-162-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Air Force Systems Networking (7ESG)
RegDate: 1996-11-08
Updated: 2021-12-14
Ref: https://rdap.arin.net/registry/ip/162.24.0.0OrgName: Air Force Systems Networking
OrgId: 7ESG
Address: 501 E. Moore Drive
City: MAFB-Gunter Annex
StateProv: AL
PostalCode: 36114
Country: US
RegDate: 2008-06-05
Updated: 2019-06-20
Ref: https://rdap.arin.net/registry/entity/7ESGOrgTechHandle: REGIS10-ARIN
OrgTechName: Registration
OrgTechPhone: +1-844-347-2457
OrgTechEmail: disa.columbus.ns.mbx.arin-registrations@mail.mil
OrgTechRef: https://rdap.arin.net/registry/entity/REGIS10-ARINOrgAbuseHandle: REGIS10-ARIN
OrgAbuseName: Registration
OrgAbusePhone: +1-844-347-2457
OrgAbuseEmail: disa.columbus.ns.mbx.arin-registrations@mail.mil
OrgAbuseRef: https://rdap.arin.net/registry/entity/REGIS10-ARINARIN WHOIS data and services are subject to the Terms of Use
available at: https://www.arin.net/resources/registry/whois/tou/
If you see inaccuracies in the results, please report at
https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
Copyright 1997-2022, American Registry for Internet Numbers, Ltd.
-
@mvmatch just because you see a rfc1918 in your trace does not have to mean its a nat happening. While sure there could be one, it also could just mean that the router your hoping across answered with its loopback address.
Or your just going across a transit network inside your isp network, does not mean that traffic is being natted.
I use to get rfc1918 at the 3rd hop while my isp was doing some IP work.. Now it seems to be back to public space..
example if that 3rd hop is actually airforce IP range, that 162.24 address - they could just be using that inside their network as transit as well. Would be very bad practice for isp to do that, but see it all the time inside datacenters where like to use dod space for their internal networks. My old company did this.. Not a fan of the practice - but it happens a lot to be honest.
A rfc1918 or non owned IP ranges can be used inside a private network without ill effect, your isp network is actually a local network that your connected too, doesn't mean there is nat happening.
You could prob start seeing such practice happen more an more even on larger ISPs, as IPv4 space gets more and more scarce and valuable. There is nothing saying the IPs used inside an ISP for their own internal routing needs to be public space..
Where they might of used some of their external IP space internally on their network before, now they are switching those out for rfc1918 space, or even using space that is not theirs that they or their customers would have no need/want to actually get to. So they can leverage the public IP space for their edge devices and customers.
-
Well this discussion has been enlightening. Thank you all for the education.
It's not that I can see any problem in my network connection at this time, but I'm about to configure some port forwarding and this RFC1918 hop may prevent that. Then again it might not I guess. I'll just have to try it and see.
It's still disconcerting to me to see an RFC1918 address at the first hop.
-
@mvmatch Years ago our office used an ISP that used RFC1918 internally, though we had a public IPv4 address. So it's possible to work like that, just a bit odd, and can cause a conflict if that first RFC1918 range is used on your LAN. But it's possible to do if they set up their routing tables correctly.
If you don't have a public IP though, then inbound connections aren't going to work. What is the WAN IP on your pfSense?
It is of course possible to use double NAT with inbound if the ISP modem/router is providing NAT, just have it forward all ports (maybe called DMZ) to your pfSense WAN IP. That should work for most things; IIRC inbound FTP is an exception.
-
@mvmatch said in Perhaps I'm double NATing?:
and this RFC1918 hop may prevent that.
No not if your pfsense as a public IP on its wan.. Maybe I was not clear enough about transit network(s) inside your isp that has nothing to do with nat, or your pfsense actually being exposed via a public IP.
maybe this helps?
So your pfsense has a 4.5.6.x address on its wan, this is a public IP.. And the internet knows how to route to get there, at some point it will hit the actual ISP edge network in routing to get there.. Once that traffic hits your isp edge saying hey I want to get to this 4.5.6.x address - doesn't matter what the internal hops inside the isp IP address are..
The router at the edge 1.2.3.4 sees traffic saying it wants to go to 4.5.6.x, says oh next hop is 162.24.179.2 lets say, and that router says oh you want to get to 4.5.6.x send it to 172.24.179.2.. This router says oh yeah I am connected to that let me send that to your router at 4.5.6.x.. Your router says oh I have a port forward that says if traffic to my address wants to go to port 443, send it to 10.1.1.x
The only place nat has to happen is at your router, converting your 10.x address to a public IP..
-
@steveits
Sorry Steve, I'm a little slow. It's been many years since I was a sysadmin, and frankly I've forgotten most of what was routine since my retirement. I'm just grateful for the discussion.It's a public address. 76.63.something.something. I looked this up a few days ago. Don't remember exactly, maybe 76.63.3.9? but the gateway is 76.63.2.1 I'll look up the WAN addy to confirm if needed.
-
@mvmatch have you blocked port 443 form accessing DNS?
"Similar to DNS over TLS, clients may also use DNS over HTTPS (DoH). This is harder to block as it uses port 443. Blocking port 443 on common public DNS servers may help (e.g. 1.1.1.1, 8.8.8.8).
Some browsers automatically attempt to use DNS over HTTPS because they believe it to be more secure and better for privacy, though that is not always the case. Each browser may have its own methods of disabling this feature. Firefox uses a “canary” domain use-application-dns.net by default. If Firefox cannot resolve this name, Firefox disables DNS over HTTPS.
To prevent Firefox from using DNS over HTTPS, add the following to the DNS Resolver custom options:"
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html
-
@mvmatch see my edit of last post with a little drawing - maybe that will help you understand that ISP can use internal rfc1918 space without a nat..
