Strange behaivor in pfsense firewall rules .



  • I dont know if anyone here notice , but if you are using firefox , chrome and other popular internet browsers , by default without user knowing , when you open firefox without any plugin activated or maintenance service from browser , or even a startup page configured , Firefox connects automatically to some remote ips in http ports and https .
    So i decided to start blocking those ips on Pfsense , and i created rules to prevent any type of protocol could connect to those specific ips .

    I applied most of the rules last night , but some ips show me established connection to those ips blocked , and some of them are even able to bypass the firewall !!!

    I used tcpip tool to monitor firefox and catch the ips , and i made print screen of tcpip capture and the firefox rule that is blocking that ip .
    I see connection established and bytes in and out from that ip address .

    Tcpip capture (i made a red box on the ip blocked in pfsense ):

    Pfsense rule blocking that IP :

    Does anyone have a clue why this ip is bypassing pfsense firewall ?

    Note : If i open in browser that ip on https , it not shows anything , but it looks that some bytes pass thru the firewall .


  • LAYER 8 Netgate

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

    If a new rule was made to block some traffic, but packets still get through, there may be an existing state that is allowing the traffic to pass.

    To eliminate this as the cause, clear the states (Diagnostics > States, Reset States tab) after altering the rules. If there is an existing state, it will always take precedence over any rules. All of the states may be cleared, or look/filter through the list and find states that apply to the host that will be originating the traffic.

    And for things like that, you might try Reject instead of Block so the connection attempt fails immediately instead of having to time out.



  • thanks for the tip  on clearing the states in diagnostic menu .
    Usually i  choose to reject the packets instead dropping them  , but as "rejected" was not working and i changed to drop to see if it worked that way , but the problem was that i did had cleared the firewall states .
    Any clew why it says "established" , if firewall is blocking?
    I say this because in other firewall i have here these type of rules say that are unable to synchronize with specific ip address , and in this it say established , but no packets are forwarding or receiving , so why established if there is no connection between them ?


  • LAYER 8 Netgate

    No idea what you're looking at. If the SYN is blocked you can't have an established connection.

    You could be looking at a dangling state/connection on the target host.



  • I knew something is not right , even after creating the rules in firewall , the connection appears to be established to those ip addresses even if there is not data exchange between  them .
    I  connected by network cables to my watchguard firewall here witch is only 100Mbit ports , and the rules are the same but the result is different .

    By this , it means that i don't figure out yet why my gigabit firewall allows the connection to be established while the watchguard hardware does not .
    In this case , watchguard is doing its job perfectly .
    I downgraded from latest version my gigabit firewall to 2.1.5. witch is my watchguard version , and the results are the same i get in 2.2.6.

    Note : all these captures were made only in one session of firefox opened without any url , just a blank page  . Firefox when is not able to connect to a specific ip address , then tries other ones , until it gives up .  One thing strange that i notice is that firefox open to those ips an http connection and https connection at same time for each ip .



  • Problem Solved .
    I think that some rules were not exactly like it was in watchguard hardware , so i backed up the firewall rules from watchguard and applied them on my gigabit firewall , i solved the problem .



  • Order matters for the rules in pfSense.  User added rules are evaluated as first match wins, so if your block rule was below one that was allowing the traffic, it winds up not getting hit.
    You also need to make sure that the rule is added to the correct interface;  assuming your client is on your LAN interface, you would add the rule to the LAN tab.  WAN tab is for traffic coming into the pfSense box from the outside world.
    That's why a lot of times people ask for screenshots of your rules;  saves alot of assumptions.


Log in to reply