Block Private Networks From Leaving PFSense
-
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
