Block Private Networks From Leaving PFSense



  • Hello, I would like to restrict any private network range (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) form ever leaving PFSense! Is this possible? For example! 192.168.100.0/24 is not a network on my range, but I would like if someone tries to access it that the request is discarded by pfsense. How can I do this?

    For example, if I try to tracert 192.168.100.1 on my computer I can see that the request leaves PFSense by a gateway.

    I tried to apply this logic in the LAN Interface, but if I put "Block > (src) Lan Net > (Dest) PrivateNetworkAlias" I'm blocking all accesses to Private Networks, even internal access.

    Thank You All



  • If you use your local networks in the allow-rule instead of any there is no need to block other networks.


  • Rebel Alliance Global Moderator

    What does it matter if someone tries to go to 192.168.100.1 ??  Yes pfsense by default would send that to its default gateway, that is how networking works.. Hey I don't have that network locally attached, I don't have any specific routes to that network to go out any local networks to a gateway to get there.. So send it out my "default"

    But if you wanted to block it, then as mentioned create an allow rule for your Networks..  Then a block rule for rfc1918 space, then your typical allow rule that allows users to the internet..



  • 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


  • Rebel Alliance Global Moderator

    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?



  • 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


  • Netgate

    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



  • 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



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



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


  • Netgate

    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.



  • @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



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



  • @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


  • Netgate

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


  • Rebel Alliance Global Moderator

    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



  • Netgate

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



  • @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


  • Rebel Alliance Global Moderator

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


  • Netgate

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


  • Rebel Alliance Global Moderator

    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…



  • @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



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

    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


  • Rebel Alliance Global Moderator

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



  • @johnpoz:

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

    The 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


  • Rebel Alliance Global Moderator

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

    this list include also RFC1918.


  • Rebel Alliance Global Moderator

    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.


  • Netgate

    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