PFSense talking out with all rules set to block



  • Been trying to track down some traffic going out even though I have totally set the rules to block everything temporarily.

    In desperation I enabled "Log packets matched from the default pass rules put in the ruleset" in the firewall log settings and got my answer after seeing several autorules in the firewall logs..

    "let out anything from firewall host itself" And it shows it's on the WAN INTERFACE e with an arrow indicating outgoing.

    I didn't know it can use WAN in the opposite direction (as outgoing). It is sending out UDP to various places, some timeserver, some dns, and also looking for updates.  But also some packages are also firing off various ip's of their choosing as they please. This is fine and dandy except the role of this particular box is not to talk out on it's own.

    I can see from the log it must be using some hidden floating rules. Does anybody know how to stop this with a ruleset? Yes, I can kill the timeserver and dns. But I want all this to work again with just passing/blocking a rule.



  • The firewall only blocks on ingress when a new state is created. If the state is not new or the packet is not received as ingress, then it is not blocked. What this means is packages running in PFSense do not honor.

    PFSense doesn't block outgoing data, it blocks incoming data. If you decide to run software on PFSense, then there is no interface for the packet to be received on, meaning it does not get blocked.

    I'm sure there are some exceptions.


  • Rebel Alliance Global Moderator

    And what packages are you installing?  On a box that is not suppose to generate any traffic?

    "the role of this particular box is not to talk out on it's own."

    So is this box static on its wan - if not it would have to generate atleast renewal of its dhcp IP?  Its going to generate ARP traffic for sure..  I think you idea that you can put something like a firewall distro with packages of other applications, etc. etc. and not expect it to put traffic on the wire is unrealistic at best..  If you don't want it checking for updates, turn that off, if you don't want it doing dns - turn that off, etc..



  • If you want absolutely ZERO traffic on the WAN, unplug the cat5.


  • Banned

    @kevin067:

    the role of this particular box is not to talk out on it's own.

    I can fix it easily for you:



  • What kind of traffic are you seeing? You might be able to get most of the traffic stopped by disabling features in PFSense. Most of PFSense's traffic has to do with checking if the link is alive and looking for new versions.

    johnpoz hit most of these points. There is going to be come traffic that you can almost never get rid of, like ARP, or DHCP if you have that. You also have that PFSense is a stateful firewall, so if dup packets are received, PFSense is going to respond with a DUP ACK, which is pretty much built right into the network stack.

    Show us some examples of what traffic you want to get rid of, but it is unrealistic to think you can get rid of all traffic.



  • When I say outgoing traffic I am talking about the box talking out to external IP address's on it's own. No client on the LAN initiated any communications. This is what this box is all about right?

    The logs show outgoing (out arrow) on the "WAN" interface not LAN, as the box itself is doing this. It seems any package on the box has free reign to do as it pleases with no ability to block them. You will not see these log's even unless you enable view default pass rules. Even if you have set all your rules to logging.

    Turning off features isn't the problem, it's the various packages. I have seen it now accessing everything from google to websites in the UK. This box is in a secure environment and cannot be updating itself unannounced.

    Is there not a way to set a rule to block WAN out?


  • Rebel Alliance Global Moderator

    If you need to block outbound, you should be able to setup floating rule to block outbound on any interface.

    https://doc.pfsense.org/index.php/What_are_Floating_Rules

    Floating Rules are advanced Firewall Rules which can apply in any direction and to any or multiple interfaces. Floating Rules are defined under Firewall > Rules on the Floating tab.

    Many firewalls do not need any Floating Rules, or may only have them for the traffic shaper. For those choosing to use them, they can make some complex filtering scenarios easier, at the cost of being a little harder to follow logically in the GUI.

    More advanced/low-level options are available on Floating Rules than can be found on normal per-interface rules.

    Floating Rules can:

    Filter traffic from the firewall itself
        Filter traffic in the outbound direction (all other tabs are Inbound processing only)
        Apply rules to multiple interfaces
        Apply filtering in a "last match wins" way rather than "first match wins" (quick)
        Apply traffic shaping to match traffic but not affect it's pass/block action
        Much more.

    Floating Rules are parsed before rules on other interfaces. Thus, if a packet matches a floating rule and the Quick option is active on that rule, pfSense will not attempt to filter that packet against any rule on any other group or interface tab.

    Rules using the Queue action do not work with quick checked.

    edit:  In a perfect scenario, all packages would list what traffic they might do, and in a perfect world be able to turn off or edit that functionality - but as we all know, no such thing as perfect anything ;)



  • I had experimented earlier with the floating rules just to pass and log. I Did not see any log entries from these outgoing wan packets. So I don't expect it would have blocked it either.


  • Rebel Alliance Global Moderator

    Ok as quick test, I went in and created a floating rule to block icmp out wan.  Since I know for sure that firewall sends those out like every second.  And there is widget showing if gateway is online, etc..

    So sure seems to be blocking to me.  See the floating rule, set to log and in the logs, and widget shows gateway is offline.

    Now I did have to reset the state that was there for icmp on the wan.  Once I cleared that state then blocking was instant.










  • Hmmm, I completely forgot about resetting states!! Probably why I didn't see results….

    So I will give it shot! Thanks,

    If you ask me, blocking wan (outgoing) is the first thing everybody should be doing, and then giving permission only to what you see and know is supposed to be there.


  • Rebel Alliance Global Moderator

    If I didn't trust pfsense - why would I be running it in the first place??  Same goes for the packages..

    Not all of us have our tin foil hats on so tight, some of us wear them fashionably cocked to the side, etc..



  • My tinfoil is wrapped so tight my eyes are bulging out….

    And I still trust pfsense.


  • Banned

    @kevin067:

    If you ask me, blocking wan (outgoing) is the first thing everybody should be doing

    Block WAN access from your LANs all you want. Blocking WAN traffic from the firewall itself it a sure way to screw up things badly. As an example, notice the nifty "offline" gateway pic above. How cool is that?



  • Some people get bored with the all-green motif that is typical with pfsense.  Some people just like a dash of red.



  • I get paid to wear a tin hat, and a pfsense box is for tinhats. The reason I am even asking these questions is because this is in a high security area, and I was contacted that this box was busy with traffic when it was supposed to be offline. The only reason anybody caught it is because they inserted another router in between it and watched the logs on that.

    this box had a new user. And an extra cron job in there. After comparing the folder structure, somebody had uploaded a package and it was busy talking from the WAN out. Neither looking at the firewall logs or blocking all the rules revealed or stopped it.  In fact the "only" way to tell anything was amiss was the enabling of the "log pass rules".

    So all it takes is for somebody to get access to the shell and load in a package and that's all it takes. They don't even have to bypass any rules.

    Whether it was hacked in-house or not. It would have been caught and prevented if the box didn't automatically pass and hide. Because we would have seen the rules altered.  (Which is usually what happens when they hack in)



  • Well - Lets say you have a well known IP that people want into.  And lets say its connected and set up with WAN connected.  And lets say the default username/pass wasn't changed for even an hour.  And lets say SSH was turned on for that hour…

    Then yes - even without fingers on the keyboard, someone could co-opt the entire system.

    Even easier if they have hands on the keyboard.  It needs physical security.



  • So all it takes is for somebody to get access to the shell and load in a package and that's all it takes. They don't even have to bypass any rules.

    If someone gains shell access and has privs to install a package, then they can easily change anything else they want, including first turning off rule logging, clearing any local logs,…
    Once someone unauthorised has gained root access, then anything can happen.

    There are a few things that pfSense will "phone home" for - checking for firmware updates, version status of packages, updating bogons come to mind. Maybe it would be useful to have an Advanced config button "Do not phone home" that disabled all these things. Then people who want it to be that quiet on WAN can check the box. (And uncheck the box when they want to do an auto firmware upgrade or a package install)



  • "this box had a new user" - Sounds compromised….



  • Yes the box was compromised, and that's the point. Can be hacked from the outside or from within the company, doesn't matter. It still should have been visible to the multitude of built-in tools to monitor the traffic, "EXCEPT" when it goes "out" the wan interface.

    At a minimum wan out needs to default block, and the packages should be forced to register their ip's in a whitelist that you can see and control. (just like the rest of the box) Any new unexpected traffic will be forced to add to this white list. or will be blocked. No free ride for packages, or even pfsense itself.



  • And after several days, my other posts about solicited/unsolicited traffic still has not been answered definitively, nor can I find documentation on exactly how this works.

    I ask because the way I think the box was compromised was through a proxy server the box was using. The user did his normal thing with the proxy out a certain port. PFSense opens a rule on wan to allow this proxies ip to talk. Doing what it is supposed to, but then this same proxy switched to a different port later on, and had free reign to access the shell. Since this proxy has seen everything the user does remotely, it knows everything.

    Normally it would have been blocked by incoming wan rules, but it became trusted when the user did some outgoing. Now nobody has answered definitively about whether PFSense simply creates a pass wan rule restricting it to just the port it was outoing on. Or whether it's set to 'any' as far as I can determine from the logs it appears pfsense let's a solicited ip address through on any port it want's afterwards.

    And I don't see pfsense closing these rules after a TCP session is ended either. Nor do I see how it can understand (follow) UDP transactions anyway. It seems to me it just opens them up and leaves them forever.


  • Banned

    Dude. What do you want to document? The firewall itself will

    • use DNS (duh!)
    • use NTP
    • use HTTPS (FW updates, packages updates, bogons updates, etc.)
    • use ICMP/ICMPv6 for GW monitoring
    • use more of ICMPv6 as required for IPv6

    Your box most certainly was NOT compromised because of firewall-initiated traffic going out via WAN. Sigh. By disabling the above, you only breaks things, without any security improvement whatsoever.

    Also, if you want outbound traffic filtering/logging, then you need to configure outbound rules yourself and enable logging for those. Most people want outgoing traffic to flow, not to babysit the firewall for weeks monitoring what legitimate traffic is still being blocked for no good reason.

    @kevin067:

    packages should be forced to register their ip's in a whitelist that you can see and control. (just like the rest of the box) Any new unexpected traffic will be forced to add to this white list. or will be blocked. No free ride for packages, or even pfsense itself.

    Yeah, that would ultimately rock. Say with pfBlockerNG blocklists, snort/suricata rules, etc. Sigh again.



  • The pfSense default "background/unseen" ruleset is to block all ingress packets from all interfaces. Then you get a pass all rule on LAN for free in the default config that allows all incoming from LAN clients.
    The firewall can talk to itself internally (e.g. firewall processes that want to lookup a DNS name can "loopback" to the firewall's own DNS to ask for that…).
    Anything that can be originated internally can egress out wherever the routing table thinks it should go. There are no egress blocking rules.

    For most users, that is fine. But yes, some users have stricter requirements to ONLY emit packets that are white-listed somewhere. For that, you have the option to put floating rules outbound on your WANs - first to permit the things you want/need to make the firewall work, then to block all other.

    So if you require such extra checks/filtering you can put them in place as required.
    As long as that is understood, then "high-security/privacy" users can get the result they want.

    Edit: added the word "no" in italics above - I missed that important little word there about "no egress blocking rules" !


  • Banned

    @kevin067:

    Can be hacked from the outside or from within the company, doesn't matter.

    Still shaking my head… How on earth this does NOT matter?  :o

    So, you're gonna plumb your "phone home" WAN and call it a day, only to find out that someone attached a keyboard and monitor and compromised it again? Or compromised it again because he sniffed your password on LAN because you don't use HTTPS, or have it written on the yellow sticker on your monitor, or have a keylogger on the computer you are using? Or just because you created some user account and gave it some privileges without thoroughly understanding what are they able to do with those?

    What measures have you taken to secure the administration access to the box? From inside, from outside, physically...  ???



  • @kevin067:

    Yes the box was compromised, and that's the point. Can be hacked from the outside or from within the company, doesn't matter. It still should have been visible to the multitude of built-in tools to monitor the traffic, "EXCEPT" when it goes "out" the wan interface.

    At a minimum wan out needs to default block, and the packages should be forced to register their ip's in a whitelist that you can see and control. (just like the rest of the box) Any new unexpected traffic will be forced to add to this white list. or will be blocked. No free ride for packages, or even pfsense itself.

    The firewall is meant to manage traffic moving through it. If you don't trust the packages on the firewall, then don't install them on the firewall, install them somewhere else. And as before, you block traffic coming in, not going out. If you ever configure a managed switch, don't EVER use ACLs on egress, it'll kill your switch's CPU, only do ingress ACLs. Same idea, it's faster to do ingress ACLs.