Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Strange behaivor in pfsense firewall rules .

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 3 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P Offline
      pedropt
      last edited by

      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 .

      1 Reply Last reply Reply Quote 0
      • DerelictD Offline
        Derelict LAYER 8 Netgate
        last edited by

        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.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • P Offline
          pedropt
          last edited by

          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 ?

          1 Reply Last reply Reply Quote 0
          • DerelictD Offline
            Derelict LAYER 8 Netgate
            last edited by

            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.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • P Offline
              pedropt
              last edited by

              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 .

              1 Reply Last reply Reply Quote 0
              • P Offline
                pedropt
                last edited by

                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 .

                1 Reply Last reply Reply Quote 0
                • M Offline
                  mer
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.