nonexistent LAN addresses route to WAN
-
I tracert-ed a nonexistent LAN address, and found that pfSense routed the packets to the WAN. This is technically correct (in that unknown addresses should get routed through the default gateway, which goes to the WAN in my case), but should be prevented for RFC1918 addresses by a default firewall rule. Adding a floating rule on the WAN interface, direction OUT, destination RFC1918 (alias for 192.168.x.x, etc.), protocol IPV4 works to prevent this.
-
What are you asking exactly?
Yes any unknown network would route out the default route - that is how routing works ;)
If you do not want traffic for unknown rfc1918 address to go to your default gateway.. Yes you can create a rule to stop it.. An outbound rule in floating is prob the easiest way to accomplish that yes.
example
You would also want to make sure you set that rule as "quick"
https://docs.netgate.com/pfsense/en/latest/recipes/rfc1918-egress.html
-
IIRC, a firewall rule doesn't apply from the interface that's connected to the network. If you're using NAT, the packets are coming from the WAN interface, not a local subnet. If you weren't using NAT, the filter would likely block it.
-
@johnpoz : Shouldn't pfSense have a default rule preventing the routing of LAN addresses onto a WAN interface that acts as a gateway to non-private networks, since RFC1918 addresses are never supposed to appear on non-private networks?
-
@jknott I added a floating rule (which allows you to specify the direction) preventing RFC1918 addresses from exiting the WAN interface. Since the nonexistent RFC1918 address in question is the destination, it doesn't get NAT-ed.
-
If it goes out the WAN port, it gets NAT-ed, which means it originates in pfsense, even though the original packet originated elsewhere. Take a look at the source IP address to see that. You will see your WAN address, not that of the originating device. If it was just routing you would see the originating address, not WAN.
-
@johnpoz said in nonexistent LAN addresses route to WAN:
https://docs.netgate.com/pfsense/en/latest/recipes/rfc1918-egress.html
Thanks. That explains the issues nicely.
-
@jknott said in nonexistent LAN addresses route to WAN:
If it goes out the WAN port, it gets NAT-ed, which means it originates in pfsense, even though the original packet originated elsewhere. Take a look at the source IP address to see that. You will see your WAN address, not that of the originating device. If it was just routing you would see the originating address, not WAN.
The case I am discussing is tracert-ing an RFC1918 address (e.g., 192.168.10.1 on my LAN) which does not exist on the LAN side. Unless you explicitly block it (as by the floating rule that I and johnpoz mentioned above) the packets for such a tracert will get routed to the WAN for routing to the destination 192.168.10.1. That the source address is NAT-ed is irrelevant to the fact that the destination, an RFC1918 address, got put on the WAN.
-
@bpsdtzpw
What is the local network you're sending from? If it's any RFC1918 address, then NAT is normally used. NAT will cause all packets leaving the firewall to do so from the WAN address, not the LAN address, so the rule won't apply. As I said, use Packet Capture to see that. -
@jknott said in nonexistent LAN addresses route to WAN:
@bpsdtzpw
What is the local network you're sending from? If it's any RFC1918 address, then NAT is normally used. NAT will cause all packets leaving the firewall to do so from the WAN address, not the LAN address, so the rule won't apply. As I said, use Packet Capture to see that.The question is not the source address, to which NAT applies, but the destination address. In my case, the destination address is a nonexistent RFC1918 address, e.g., 192.168.10.1. When I tracert to that address, pfSense properly recognizes that it's not on any existing subnet, and therefore routes the packets out the default gateway. Yes, it NATs the source address, but it (of course) leaves the destination address, 192.168.10.1 in this example, unchanged. This causes an RFC1918 address to appear on the WAN, which is improper. Hence I added the outbound rule, which does in fact work as indicated by tracert failing after I added it, and pfSense logging the blocking of the packets intended for the bad address.
-
The question is where that packet originates. If you're using NAT, which is the case for most IPv4 users, then it originates at the WAN interface and so the rule does not apply. If you have a public IPv4 subnet on your LAN, then pfsense is routing, not using NAT, and the packets originate on the LAN and will be filtered by that RFC1918 rule. Using NAT to reach the Internet is the exact same situation as pinging from the pfsense box itself. In both cases the packet originates at the WAN interface. Again, fire up Packet Capture to see this. See if you can tell the difference between a ping originating on your LAN or on pfsense.
-
@bpsdtzpw said in nonexistent LAN addresses route to WAN:
Shouldn't pfSense have a default rule preventing the routing of LAN addresses onto a WAN interface that acts as a gateway to non-private networks
That could cause all kinds of issues to be honest. What if user is using pfsense downstream of a rfc1918 network with lots of rfc1918 address space.
The link I provided goes over some of this.. It is very common for users to be behind a double nat while using pfsense. The default block rfc1918 rule on wan prevents unsolicited inbound into pfsense from rfc1918. But if also blocked outbound to rfc1918, that could cause a lot of confusion to why their pfsense doesn't work for new users - that is my take on it.
Out of the box the way it is - you could put pfsense connected to a rfc1918 on its wan, and as long as it doesn't over lap with the lan side of pfsense - pfsense would work for getting to the internet throught the rfc1918 transit on its wan.
-
@jknott said in nonexistent LAN addresses route to WAN:
The question is where that packet originates. If you're using NAT, which is the case for most IPv4 users, then it originates at the WAN interface and so the rule does not apply....
The rule is a floating rule, on the WAN interface, with direction "out" and type "quick", with source "any" and destination "single host or alias" with alias RFC1918 specified. This rule definitely blocks egress from the WAN interface of packets containing RFC1918 destination addresses.
-
I was referring to the default RFC1918 rule on the WAN interface. If you want to use an ordinary, non floating rule, it would be placed on the LAN interface, to keep the packets from reaching pfsense and NAT.
-
BTW, here's a rule I created a few years ago, to keep Unique Local Addresses, the IPv6 equivalent of RFC1918, from going out to the world.
-
There are many situations where you would not want to block RFC1918 as destination.
On my home firewall both my ISPs use private IPs for the gateway for example. So the default gateway monitoring would fail.
It's non-routable anyway so that traffic goes nowhere.
Steve
-
@stephenw10 said in nonexistent LAN addresses route to WAN:
It's non-routable anyway so that traffic goes nowhere
Those addresses are routeable, just not allowed on the Internet.
-
Well not by anything that counts! But, OK, not in the way 169.254 is non-routable.
Anyway the fact RFC1918 IP destinations are sent out of the WAN is not a problem and is required in some situations.
Steve
