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

    WebGUI inaccessible on Bridge

    Firewalling
    4
    8
    4.2k
    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.
    • V
      Vard0
      last edited by

      Hi.

      I have pfSense set up with 3 interfaces:

      WAN
      LAN
      opt1

      WAN & LAN are Bridged and the bridge is assigned to opt1.

      WAN and LAN interfaces are set to none and opt1 is set to a Static IP address which I am using to access the WebGUI.  The default anti-lockout rules on the LAN interface are therefore not applicable.

      I have disabled filtering on all bridge member interfaces (net.link.bridge.pfil_member is set to 0).

      The WebGUI is set to https: on port 8181.

      All filtering is working perfectly except that I am getting locked out of the WebGUI when rules are applied.  The firewall logs shows blocked packets with TCP:FA, TCP:PA and TCP:SA flags, all on the bridge interface.

      I´ve tried setting up rules to allow all TCP traffic from the management IP to any destination (and vice-versa) with any flag set and I am still getting locked out.  Any suggestions?
      Thanks

      1 Reply Last reply Reply Quote 0
      • P
        podilarius
        last edited by

        Can you post the rules you are using?

        1 Reply Last reply Reply Quote 0
        • V
          Vard0
          last edited by

          Thanks a lot for your reply.

          Here are the rules I have set as well as a sample of the firewall logs.

          Rules1.jpg
          Rules1.jpg_thumb
          Rules2.jpg
          Rules2.jpg_thumb
          Logs.jpg
          Logs.jpg_thumb

          1 Reply Last reply Reply Quote 0
          • P
            podilarius
            last edited by

            You are looking at floating rules. These rules work off last matching unless set specifically on the rule to match immediately. What rules do you have set on the bridge interface and on WAN and LAN? I would suggest putting in allow all in LAN and WAN, and then filtering with rules on the bridge and not in floating.

            1 Reply Last reply Reply Quote 0
            • V
              Vard0
              last edited by

              Thanks podilarius.

              Both rules are set to apply immediately if matched.  I don´t have many rules but they are all applied as floating rules and all are working very well except for these two.

              I don´t have any rules on the WAN interface or the Bridge interface.  The only rule on the LAN interface is the default anti-lockout rule.

              I have disabled filtering on the member interfaces so I wouldn´t have thought I would need any rules on the WAN / LAN interfaces.  But I see some blocks originating from the LAN interface…...    Unless I am overlooking something.

              1 Reply Last reply Reply Quote 0
              • B
                btarrh
                last edited by

                Give this link a try, this is a write up I have submitted to pfSense. We manage our interface from the WAN instead of any of the other interfaces, seems to work.

                http://people.pharmacy.purdue.edu/~tarrh/Transparent%20Firewall-Filtering%20Bridge%20-%20pfSense%202.0.1%20By%20William%20Tarrh.pdf

                1 Reply Last reply Reply Quote 0
                • C
                  CliftonR
                  last edited by

                  Hi Vard0.  If you look just a few threads down below yours, you'll find my report of exactly the same problem, with a few more details.

                  My initial configuration was essentially identical to yours - opt1 bridging the LAN and WAN interfaces, each of which was a physical network interface.  I spent days on this and I tried a lot of configurations and most of them would seem to work for a bit, then suddenly the WebGUI would go away following a rule change.  I can't absolutely swear to it that I tried putting the management address on the WAN interface, though I think I did, but from what I saw of the problem mechanism I'd expect that to have the same issues.

                  Based on tcpdump sniffing, the issue seems to be that at some point, often following a rule update, the web GUI starts answering TCP connections from the wrong interface of the bridge, and its reply packets do not get bridged over to the interface the query is coming in from, so a connection to the SSH or HTTP port never completes.  ???

                  In the end, this past Saturday I started over from scratch, enabled VLANs in the initial setup prompt, created a separate VLAN sub-interface on one of the network cards, and declared that to be "LAN" and to have the management address.  I then declared the network card to be an optional interface (renamed INTERNAL) and bridged that with the WAN interface.  That's working fine now.

                  If putting the management IP on the WAN works for you, great!  Just mentioning this as another option.

                  1 Reply Last reply Reply Quote 0
                  • B
                    btarrh
                    last edited by

                    Updated version.

                    http://people.pharmacy.purdue.edu/~tarrh/Transparent%20Firewall-Filtering%20Bridge%20-%20pfSense%202.0.2%20By%20William%20Tarrh.pdf

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