Block Private Networks From Leaving PFSense
-
How's this for the wiki?
DP
How to prevent RFC1918 (private subnet) traffic from leaving pfSense via the WAN port.
Introduction
RFC1918 addresses are private network IP addresses commonly used behind firewalls like pfSense to allow a single public IP address to be shared with multiple devices. pfSense uses NAT to translate these internal IP addresses to the public WAN IP address. The default installation assigns the 192.168.1.1/24 address space to the LAN interface, but RFC1918 also defines three valid CIDR ranges for private use:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16As a general rule, it is good practice to prevent any network traffic intended for RFC1918 subnets from leaving the firewall via the WAN interface. Preventing errant internal LAN packets from leaking out the WAN interface avoids unnecessary traffic on the WAN link, as well as provides a small security benefit by keeping information about the LAN network behind the firewall.
Scenarios where RFC1918 addresses should NOT be blocked on the WAN interface
In its default configuration, pfSense is not configured to block RFC1918 addresses from being routed from the LAN subnet to the outside WAN, because there are two common scenarios where blocking this traffic is not desirable:
-
ISP assigns a RFC1918 address to individual customers - Some ISPs assign private network addresses to their customers and perform their own NAT for customer traffic to the public internet. Verify this by looking at the WAN interface IP address on the pfSense dashboard. If the assigned address is from one of the private IP ranges listed above, RFC1918 traffic should NOT be blocked.
-
pfSense is "chained" behind another device like a consumer firewall or wifi router (double NAT) - In this case, pfSense performs NAT for devices connected to the pfSense LAN, and the WAN port forwards traffic to the upstream device, where it undergoes a second NAT before entering the public internet. This is verified using the same steps as above - if the WAN IP address is from the RFC1918 range, do NOT block this traffic from exiting the WAN
If either of these scenarios apply to the pfSense installation, do NOT add additional RFC1918 traffic blocking to the WAN interface - pfSense is already configured properly for these scenarios
Steps to block RFC1918 traffic from leaving the WAN interface
For installations where the above scenarios do not apply, an additional firewall rule can optionally be put in place to prevent RFC1918 traffic from leaking out on the WAN port. This provides a small increase in security and privacy by preventing information about the local LAN from being routed further upstream on the WAN.
An example where this rule might be helpful is if a machine on the local LAN (192.168.1.1/24) is misconfigured to access a private LAN address (192.168.100.1 instead of the intended 192.168.1.1). Because pfSense does not have an explicit route for 192.168.100.0/24, the request for 192.168.100.1 will be routed out the WAN interface as normal outbound internet traffic. A misconfiguration like this could potentially provide information about the private LAN to someone with access to the ISP's WAN network. A malicious user could even set up an imposter machine on this network to answer to 192.168.100.1 and pretend to be a machine on the local network.
While the chance of this being a problem is quite small, the odds of unintentional RFC1918 traffic hitting the WAN will increase for installations with more complex LAN topologies, a large number of users, or routes that may frequently change (VPN routes, etc). In these scenarios, it may be beneficial to add a firewall rule preventing RFC1918 traffic from egressing the WAN interface.
Adding a firewall rule to block RFC1918 egress traffic on the WAN interface. In pfSense, navigate to Firewall > Aliases:
- Create an alias for the networks you want to block. Call it, say, private_networks and include the following ranges:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
(optionally include other non-public CIDR ranges like 169.254.0.0/16 and 127.0.0.0/8)
Now add a new floating firewall rule under **Firewall > Rules, Floating tab *** Action: Reject
-
Quick: Checked
-
Interface: WAN (you can select multiple interfaces or interface groups here, do NOT select your local LAN)
-
Direction: out
-
TCP/IP version: IPv4
-
Protocol: any
-
Source: any
-
Destination: Single host or alias: private_networks
-
Log: your choice
Save the changes and reload the firewall. Verify that local LAN and internet connectivity are still working.
Notes
Adding this rule to the pfSense firewall will block access to bridge devices like cable modems or upstream routers outside of the WAN port. For example, many cable modems use an IP address of 192.168.100.1. This may or may not be desirable behavior for users. The RFC1918 firewall rule needs to be disabled if access from inside the LAN to this device is required.
On the edit interfaces screen (Interfaces > WAN, for example) there is an option to Block private networks. This is a rule blocking inbound traffic, not outbound like the rule above. As long as pfSense is not behind a WAN that uses private addressing, both rules are desirable and should be enabled.****
-
-
Adding this rule to the pfSense firewall will block access to bridge devices like cable modems or upstream routers outside of the WAN port. For example, many cable modems use an IP address of 192.168.100.1. This may or may not be desirable behavior for users. The RFC1918 firewall rule needs to be disabled if access from inside the LAN to this device is required.
Or you can just add a pass rule to the cable modem address above the block rule with quick checked, enabling that rule when you need to get at the modem, disabling it otherwise (if you want to be super-vigilant.)
-
No I tried that.. That doesn't seem to work.. I Placed a rule above the floating rule that allows 192.168.100.1 but doesn't work.. To be honest getting to 192.168.100.1 from your public IP on your wan shouldn't work anyway.. But it seems too.
Looks like a nice write up though, do you have an account to post in the wiki? If not I can post that for you - but you should get your own account. You most likely have other things worth contributing as well…
-
Looks like a nice write up though, do you have an account to post in the wiki? If not I can post that for you - but you should get your own account. You most likely have other things worth contributing as well…
I don't have an account yet, but I just submitted a request to the wiki admin so I can submit
DP
-
No I tried that.. That doesn't seem to work.. I Placed a rule above the floating rule that allows 192.168.100.1 but doesn't work.. To be honest getting to 192.168.100.1 from your public IP on your wan shouldn't work anyway.. But it seems too.
I tried to test a 192.168.100.1 floating pass rule and I ran into the same issue. It turns out, the pass rule needs to have direction set to any instead of out. I even disabled the RFC1918 out rule and had the same result, so I'm assuming the 192.168.100.1 out pass rule is also blocking the connection somehow. Maybe because of the quick option?
Either way, a floating rule for 192.168.100.1, any direction, WAN interface should do the trick as long as you don't have any 192.168.100.0/24 internal routes in place. Also clear states in between rule changes.
Edit: Actually, if the quick option is working the way I think it is, it might be a really bad idea to add an any direction pass exception for 192.168.100.1 to your firewall. The reason is that an inbound connection from the WAN on that address might hit the quick floating pass rule before it hits the WAN interface inbound RFC1918 block - meaning that you just gave the modem full access to route packets inside your LAN, which is basically worst thing to do with these modems. I don't have an easy way to set up a machine on the WAN to test this right now though.
DP
-
Well if the rule is written as dest 192.168.100.1 even if seen as inbound rule to your firewall/nework on the wan interface. There is nothing listening on 192.168.100.1 on your firewall, or for sure there shouldn't be if your modem is using that IP.
So even if it let traffic in with that dest, where would it go?
But it is odd that you would have to set it to any.. When I did my test I just set it to out.. And put above the rfc918 block.. What was the actual rule you created. I tried to be as specific as possible and set tcp 80 out on wan to 192.168.100.1
Its not very often I access that modem interface… I takes all of 2 seconds to disable the rfc1918 block rule if I ever need to, etc. So didn't think much more about it.. BTW still no hits on my outbound rule ;)
-
Well if the rule is written as dest 192.168.100.1 even if seen as inbound rule to your firewall/nework on the wan interface. There is nothing listening on 192.168.100.1 on your firewall, or for sure there shouldn't be if your modem is using that IP.
Yeah, that's a good point, it would still have to be dest 192.168.100.1 so it wouldn't be as open as I thought.
I'm not really sure why a direction any rule would work and an out rule would not. Specifically I tested with this:
Floating rule
Pass
Quick on
Interface WAN
Direction any (out didn't work)
IPv4
Protocol any
Source any
Destination single host 192.168.100.1The funny thing is that if you disable Derelict's block rule and only add the rule above with direction out, the modem is made inaccessible. You can make the modem accessible by either changing direction to any or removing the pass rule. It feels like there is some sort of NAT or asymmetric routing complication happening with the return path through the WAN interface when that pass rule is in place. I guess it could be something particular to my setup though, I didn't go too deep into testing it as I'm perfectly happy blocking the modem completely.
I also found an unexpected benefit of explicitly blocking RFC1918 outbound on the WAN port. Now when I fat finger a private subnet address or otherwise try to access a RFC1918 subnet I don't use, I get an instant "Destination Host Unreachable" and connection failure due to using a reject rule vs. routing the packet to get lost on the WAN. It's nice to get the instant feedback instead of hitting a timeout.
Jim set me up with wiki access, so I'll submit the howto as soon as I'm able to spend some time formatting it properly.
DP
-
I am very impressed with the level of detail you put into the article, add some pictures and will be cooking with gas ;)
Having some wife time tonight, so no computer play time for me ;) But I will test out using an any rule for the modem.. It is odd, but since to be honest it really shouldn't work anyway. Think about it your wan interface has a public IP, its for sure not in the 192.168.100 segment. So being able to talk that IP outside your wan really shouldn't work, and is not how you would design something to work, etc.
If anything you should have to put a VIP on your wan interface that puts in in that network.. And now your just running multiple L3 over the same L2 which is not really a good idea either.. Never got my curiosity level high enough to look into why it works when it really shouldn't - just knew that I could access my modem IP. I don't have any problems just disabling the rule if I ever need to get to the modem - which is really rare..
But if your looking to keeping noise going out your wan.. And you have window boxes you might want to add a block rule on the floating tab for out as well on 137… Windows for some strange reason likes to send a query on 137 to any website you hit ;)
-
Thanks, I'm happy to give back in a small way since pfSense has been such a great tool for me.
Good call on the 137 block, that's a good idea to add. Maybe this can be the start of a pfSense hardening howto series (although the defaults are pretty solid already)
DP
-
For a more tighten security you can use bogon list from pfsense
https://files.pfsense.org/lists/fullbogons-ipv4.txtthis list include also RFC1918.
-
And for what possible reason would clients on your network be trying to go to bogon??
BTW yet to see 1 hit on the rfc1918, other than my tests.. If you have devices trying to go to invalid rfc1918 for your network - then you have misconfigured devices on your network is the way I look at it ;) better correct the issue there. This will won't help you find them though because its outbound on the wan.. But if your seeing a lot of it - you could start looking to who is creating it I guess.
-
Seconding the misconfigured. Since all incoming traffic is blocked by default, the only way your devices would attempt to send traffic out the WAN to rfc1918 is if your devices are configured to do so, and only to rfc1918 addresses that are not in the local subnet, and only if your WAN has an IP from said rogue rfc1918 subnet.
If your WAN has an IP from this rogue rfc1918 subnet, you have a lot of other issues to worry about. Of course this only applies if your WAN uses DHCP, so it shouldn't really affect commercial users with manually configured static blocks.
-
My main concern is traffic for remote VPN networks when a tunnel is down and there is no route.
That's pretty much the last kind of traffic I want egressing WAN.
-
I finally got around to formatting and posting this on the wiki:
https://doc.pfsense.org/index.php/Prevent_RFC1918_traffic_from_leaving_pfSense_via_the_WAN_interface
Feel free to edit/improve.
DP
-
@dparring said in Block Private Networks From Leaving PFSense:
Well if the rule is written as dest 192.168.100.1 even if seen as inbound rule to your firewall/nework on the wan interface. There is nothing listening on 192.168.100.1 on your firewall, or for sure there shouldn't be if your modem is using that IP.
I'm not really sure why a direction any rule would work and an out rule would not. Specifically I tested with this:
Floating rule
Pass
Quick on
Interface WAN
Direction any (out didn't work)
IPv4
Protocol any
Source any
Destination single host 192.168.100.1DP
I just posted a question before finding this thread. Sorry to make it live again after 5 years, but this part was not fixed.
I found this fix to use only an "out" direction, and not "any" to allow access to the Modem cable
The rule works properly that way. I need however to allow it on both WAN and the VLAN interface providing internet access because the Transit VLAN (internet only) has a rule to only allow traffic to non local interfaces. The source must be WAN address.
In my setup, I do not need the floating rule because the control is done on the local interfaces since only one can allow internet access. But just added it for testing the "out" only method
Is it safe to go with it to follow the guide recommendation while allowing access to the modem ?
Thank you
