Block Private Networks From Leaving PFSense

[Soloam]

I have several rules blocking traffic from getting out of my network, but I only what to block them if traffic is going out, so I have a rule with "!PrivateNetworkAlias" (Alias 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8), I wanted to target only traffic leaving my private space. I can replace the Alias with my specific networks, but I think that this approach is a little hacky, and would prefer a cleaner way, if it exists.

Thank You

[johnpoz]

dude post up your rules.. This can be accomplished with 2 rules, and then your default any any allow.

allow your localnetworks
block rfc1918
allow any

Put your local networks in your alias used in rule 1

I still don't understand why anyone would care.. if you did a traceroute to rfc1918 space that is not connected to your network - its not going anywhere anyway.  Other than sending a few packets to your default gateway what does it matter?

[Soloam]

From Top To Bottom

• Allow all to Private

• Block Torrent PC To Bad IP's (avoid spamming log)

• Block Bad IP's

• Block Torrent PC to Anti P2P IP's

• Exit Torrent Machin By VPN Gateway

• Blocks Torrent Machine To exit if VPN GateWay Down

• Exit Specifc IP's To VPN Gateway

• Blocks Specific IP's To exit if VPN GateWay Down

• Exit Rest By WAN

[Derelict]

I like an explicit block for this too.

Create an alias for the networks you want to block. Call it, say, private_networks.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
127.0.0.0/8

Firewall > Rules, Floating tab

Action: Reject
Quick: Checked
Interface: WAN (you can select multiple interfaces or interface groups here)
Direction: out
TCP/IP version: IPv4
Protocol: any
Source: any
Destination: Single host or alias: private_networks
Log: your choice

[dparring]

Sorry to bring up a thread from November, but I do think there is a legitimate security issue being overlooked here.  Packets intended for private network addresses should never leak out of the WAN side of the firewall unless the user specifically wants this behavior.  This opens up exploit opportunities for information gathering on the leaked packets as well as setting up imposter machines that appear to be on the local LAN.  Here is an example:

Setup:
local pfSense router 1 (PF1): WAN via DHCP cable modem, LAN is 192.168.1.0/24, IP is 192.168.1.1
remote pfSense router 2 (PF2): separate WAN via DHCP, LAN is 192.168.100.0/24, IP is 192.168.100.1
PF1 has a site-to-site VPN with PF2 that routes packets to 192.168.100.0/24 and vice versa

Exploit:
Attacker has access to the WAN network outside of PF1
Attacker sets up an imposter machine on this network at IP 192.168.100.1
Attacker disrupts or otherwise blocks the VPN tunnel, causing PF1 to attempt to reconnect, fail, and drop its route for 192.168.100.0/24
Target sysadmin behind PF1 is alerted to a problem and tries to access 192.168.100.1
PF1 silently routes sysadmin's request to the attacker's machine
Attacker continues to exploit further via password phishing, etc.

Similar approaches would be to take advantages of typos (192.168.0.1) or other changes in the routes that would cause an internal machine to think it is talking to another internal machine when it is actually an attacker outside of the firewall WAN.

This scenario sounds far fetched, but I discovered this leakage in a similar way.  While testing a site-to-site VPN, I found that I was getting ICMP ping replies from private addresses that should not have been reachable when the link was down.  A little digging revealed that upstream cable modems were replying to pings to 192.168.0.0/16 addresses because pfSense was leaking those out to the WAN.  It turns out that 192.168.100.1 is the IP address favored by thousands of disturbingly insecure Arris cable modems, meaning that this scenario is actually highly plausible - exploiting the cable modem could lead to further exploits against machines behind pfSense by routing private subnets outside the WAN interface.

I haven't have a chance to test it yet, but Derelict's solution to add a floating firewall rule on WAN egress seems to be the cleanest fix.  Would it be possible to add this as an option on the interface configuration page similar to the way ingress blocks for private networks and bogons are done currently?  My guess is that most people assume the private network ingress block prevents internal traffic from leaking out of the WAN, but that is certainly not what it does.  I think a case can be made to add this feature and make the default setting to block private network egress via WAN, with an optional ability to allow it out when it might be required - like ISPs who use private addressing for their WAN connections.

DP

[Harvy66]

"WAN" is an arbitrary name given to the concept of Internet facing. By default PFSense will block private IPs from the "WAN" and it's not going to forward packets to an interface unless the subnet is assigned to that interface.

[chpalmer]

The WAN will pass 192.168.100.1 to the modem (cable) just fine.  The cable modem wont answer to that same address on the cable side. But it will answer the "maintenance" address given it by the ISP.

Comcast has wisely chosen to use IPv6 for its maintenance addresses.  My ISP is using 10.28.x.x.  I can reach every customer modem they have using their addresses.  I can even reboot mine from my parents house using its maintenance address as we use the same ISP.

But I don't see this as a pfSense problem.  I see it as a security issue with how cable modem software is written.

[Derelict]

It is bad form to allow packets to leave your network from IP addresses that are not your routable addresses.

If more ISPs would egress filter on source addresses (they know what the addresses sourced from their network should be) a lot of DDoS techniques would be rendered impotent.

Especially on address blocks used for lower-end services.

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.

[dparring]

@Harvy66:

"WAN" is an arbitrary name given to the concept of Internet facing. By default PFSense will block private IPs from the "WAN" and it's not going to forward packets to an interface unless the subnet is assigned to that interface.

That's true for connections or packets coming into the WAN interface from outside, but pfSense will happily route and NAT a packet from source 192.168.1.xxx ingressing on a LAN interface, out to destination 192.168.100.1 on the WAN interface, where a machine on the same WAN layer 2 could respond back (or even further in layer 3 if the ISP is routing private subnets for some reason).  This happens with cable modems or other bridge devices that live outside the WAN but have layer 2 access to the WAN subnet.

Agreed that WAN is just a name - my suggestion regarding making this a new block by default is because out of the box pfSense sets up some sane rules and configs based on the WAN/LAN nomenclature.  But adding a "block private network egress" box (and checking it on initial WAN setup by default) would improve security in most common scenarios.

DP

[chpalmer]

@Derelict:

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.

[dparring]

@chpalmer:

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

[Derelict]

@chpalmer:

@Derelict:

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.

[johnpoz]

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

[Derelict]

I care enough to block it, yes. But before I did I didn't lose any sleep over it.

[dparring]

@johnpoz:

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.

@johnpoz:

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.

@johnpoz:

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

[johnpoz]

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..

[dparring]

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/16

As 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.****

[Derelict]

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.)

[johnpoz]

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…

[dparring]

@johnpoz:

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