Block Private Networks From Leaving PFSense
-
It is bad form to allow packets to leave your network from IP addresses that are not your routable addresses.
Also, as to "who cares," anything leaving out WAN with a private address is from the private side and should either be blocked or inside a tunnel.
I don't think its up to my router to lock me up… This is up to me to build the correct rules and implement. But thats just me.
I believe that my box should send any and all requests that are not aimed at my own subnet out the WAN unless I as the "keeper of the box" build a rule to explicitly deny it.
The smarter the robots get- the stupider and more replaceable the people get.
-
I don't think its up to my router to lock me up… This is up to me to build the correct rules and implement. But thats just me.
I believe that my box should send any and all requests that are not aimed at my own subnet out the WAN unless I as the "keeper of the box" build a rule to explicitly deny it.
The smarter the robots get- the stupider and more replaceable the people get.
Setting it as blocked by default is certainly debatable, but I think exposing it as an option in the interface for users to choose is a good idea regardless. That way it would be self-documenting and people wouldn't automatically assume private traffic is prevented from leaking out of the WAN side of the firewall.
pfSense already makes a number of assumptions at setup time (WAN/LAN, etc) that are sane, secure, and reasonable; my argument is that this should also be one of those assumptions. It improves security in the common scenarios that pfSense targets out of the box. I'd also argue that many pfSense users assume it is already doing this by default.
The only scenario I can think of where passing private networks out of a WAN interface is desirable behavior would be ISPs that distribute private addresses for customer WAN access. I could see this generating more support calls and forum posts if "block private network egress" were enabled by default. However, it might be possible for pfSense to be smart about it and automatically put in a minimal pass rule for whatever the WAN net is configured as (e.g. 192.168.1.33 gets a pass egress rule for /24 or whatever). That way you still get protection against leakage by blocking all other private subnets on WAN egress, and the number of support calls doesn't go up for people on those ISPs. Either way, having this available as a checkbox on the Interface Edit screen seems like a nice enhancement.
This is just a suggestion. Advanced users will either figure it out on their own or find a post like this and add in the rule suggested by Derelict. But this seems like something that would help make everyone a little bit more secure.
DP
-
It is bad form to allow packets to leave your network from IP addresses that are not your routable addresses.
Also, as to "who cares," anything leaving out WAN with a private address is from the private side and should either be blocked or inside a tunnel.
I don't think its up to my router to lock me up… This is up to me to build the correct rules and implement. But thats just me.
I believe that my box should send any and all requests that are not aimed at my own subnet out the WAN unless I as the "keeper of the box" build a rule to explicitly deny it.
The smarter the robots get- the stupider and more replaceable the people get.
I never said anything about this behavior being the default.
-
I believe that my box should send any and all requests that are not aimed at my own subnet out the WAN unless I as the "keeper of the box" build a rule to explicitly deny it.
I like this statement very much and completely agree with… By design, the router in pfsense should send any traffic it does not have other routes for out its default gateway. You as the owner of said traffic coming out of your wan to your internet default gateway can control that if you want. Blocking said traffic by default is going to be a bad idea.. Since many many users of pfsense are behind a double nat where there is an rfc1918 address on the wan.. Having it block outbound traffic to rfc1918 is going to just frustrate the hell out of those people. They can not even figure out why when they add an another interface that has not default allow rule why stuff doesn't work. Look at how many questions come up based around that, or just getting basic port forwarding to work ;)
If you don't want it sending rfc1918 out your wan it takes all of 2 seconds to create a floating rule to block it.. Pick your wan interface, pick direction out and use a rfc1918 alias = Done!
Keep in mind such a rule would block your access to your modem that is on 192.168.100.1.. As to controlling your network, I like the idea and agree - there is really no reason to send noise out your wan.. And if someone mistypes a rfc1918 they are trying to get to that would be noise.. So I have added the above rule to my floating tab.. Even set it to log -- lets see how much noise was being sent ;)
My point about who cares, is this normally is going to be some noise.. That don't get very far.. rfc1918 doesn't route on the internet, while it goes out your default gateway.. ISPs should not be passing this traffic out to the internet at large. Do you really care that your isp seems some typo's
-
I care enough to block it, yes. But before I did I didn't lose any sleep over it.
-
I like this statement very much and completely agree with… By design, the router in pfsense should send any traffic it does not have other routes for out its default gateway. You as the owner of said traffic coming out of your wan to your internet default gateway can control that if you want. Blocking said traffic by default is going to be a bad idea.. Since many many users of pfsense are behind a double nat where there is an rfc1918 address on the wan.. Having it block outbound traffic to rfc1918 is going to just frustrate the hell out of those people. They can not even figure out why when they add an another interface that has not default allow rule why stuff doesn't work. Look at how many questions come up based around that, or just getting basic port forwarding to work ;)
Thanks johnpoz, your reasoning makes a lot of sense. If a lot of users are double NATed behind private addresses, I can see it becoming a support nightmare if set to default. I can see I'm not going to win the argument to make it default, but I'd still love to see it added as a checkbox on the Interface Edit screen in addition to the inbound rfc1918 and bogon blocking. This makes it a little more self-documenting than adding a floating rule and it would expose the setting to more users who might appreciate a small security boost. And the existing inbound rfc1918 block option would break double NATed users just as easily if they choose to turn it on (the help text warns them against it), so I don't think it would increase support calls if it defaulted to off.
If you don't want it sending rfc1918 out your wan it takes all of 2 seconds to create a floating rule to block it.. Pick your wan interface, pick direction out and use a rfc1918 alias = Done!
I just added the rule to my firewalls (thanks Derelict) and it works perfectly.
Keep in mind such a rule would block your access to your modem that is on 192.168.100.1.. As to controlling your network, I like the idea and agree - there is really no reason to send noise out your wan.. And if someone mistypes a rfc1918 they are trying to get to that would be noise.. So I have added the above rule to my floating tab.. Even set it to log – lets see how much noise was being sent ;)
Blocking the cable modem is actually my original intent. The security on these Arris modems is appalling - the more isolation my network has from it, the better. And stopping any errant leaks for my ISP to record in some secret metadata database is nice too. One of the primary reasons I first got into using pfSense was the desire to replace the poorly patched, backdoor ridden hardware firewalls that everyone uses these days. Now I don't know what I would do without it.
DP
-
Well a well rounded router/firewall can be a powerful thing..
To your statement of the checkbox and the help text.. That really doesn't help much.. Look when you create a new interface what it says in the firewall rule tab about creating rules, and when you assign a interface an IP clearly says if on lan gateway is most likely NONE.. .Yet that happens all the time too ;) My fav is the source port on a nat.. Its hidden with an advanced button you have to press, then it bold letters tells you this normally any!! Yes that happens all the time too..
There are thousands and thousands, more like millions millions of those off the shelf soho routers you mention. Are they blocking rfc1918 from going out their wan gateway?? While you would hope that everyone was smart enough to run pfsense vs that junk that is those off the shelf routers.. Sadly its a very very small number compared to those soho routers. And the people that would care about such things, I would hope they are smart enough how to figure out to block something ;)
My rule has been in place for a while now – not one hit, other than my test of trying to go to my modem ;) Can tell you going to be a pretty quiet rule that not going to see a lot of traffic ;) If you feel strongly about it - put it in the wiki on how to do it..
-
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.
