Critical issue with blocking LAN interfaces



  • Network is transparent bridge.

    WAN (public static IP) and no IP on other side (so NAT is disabled and no DHCP).

    LAN1, OPT1, OPT2 is bridged along with the WAN interface. All traffic between the three LAN port should be able to pass, it should really behave like a switch.

    I have a * all pass (even on protocol) on LAN, floating, OPT1, OPT2 and even a bridge interface (not on a port).

    FW have started to block a lot of the traffick on the LAN! For instance a host on LAN1 is denied access to a device on OPT1. I see this in the fw log. When I click Easy add rule and it is added, it is added under the Allow all on the LAN1 or whatever port it was blocked on. So it is already allowed.

    The deny message says it hits "default deny" rule. But there are no deny rule on any of the local interfaces and that easy add wizard adds a rule on that same interface and still gives no result should indicate that further.

    Traffic from all LAN out on WAN seems to work just perfect.

    Is there some kind of interface I have not added? I'm clueless. Any tips is highly appricaited!

    I click the last + sign in the image and then the rule goes to LAN_SW1 (LAN1), which is a local interface. Not that it helps, because I have the allow any just above it. Running latest  2.4.1-RELEASE (amd64).

    net.link.bridge.pfil_member = 0
    net.link.bridge.pfil_bridge = 1

    WAN, LAN1 (LAN_SW1), OPT1, OPT2=bridge0





  • LAYER 8 Global Moderator

    "it should really behave like a switch."

    Sorry but then get a switch! ;)  So your wanting a transparent firewall - do you have any block rules?

    And your block there is a Ack.. So its out of state.. And yes wold be blocked.

    https://doc.pfsense.org/index.php/Why_do_my_logs_show_"blocked"_for_traffic_from_a_legitimate_connection



  • To introduce more things to manage introduces more risk (all is duplicated to avoid having to go to the datacenter in case of one line falls out - both power, network and two network interfaces in team-mode).

    When all I need is two ports, it is a bit drastic to buy enterprise switches into this (more rack-space, more cables, more outlets etc). I also have another pfSense SG-2440 (not for use in my network where I have tested the switching speed and found it to be more than good enough - I couldn't really see any delays introduced - I assume we are talking microseconds and not ms?).

    I have had the pfSense as transparent fw for two years, with only rules on the WAN-interface. The only change I have done, is to connect our second main switch to the second LAN-interface (called LAN_SW2 or physical port OPT1 of pfSense) instead of just having it serial-connected to just one main switch. So it is in parallell/redundancy-mode. We have RSTP thoughout on all switches.

    I do have block rules on the WAN-interface (against known bot-nets), but not against our own IPs and the WAN-interface shouldn't interfere with inter-LAN connections (unless there are something with this bridge-thing I migth have misunderstood).

    When it is out of state, could this be due to a network thing like above and that I should not look at pfSense to debug this error?

    In the attachment, you will see my interfaces and the bridge. I have just deleted (as you see on the image) the OPT3 virtual interface attached to the bridge in bridge.png, I assume it wasn't needed there in this setup as it didn't change anything.

    Update: I have run a commercial tool to detect duplicate IPs, and it found about 10 - but it was because they where in teams/bond/LAG-mode. Just to be sure, I have disabled one interface on every team and now it shows no duplicate ip. But still have problems.

    Update 2: Things looks more stable once I disabled the redundancy in teaming/bonding. Maybe an error in software-setup on one server unless you see any errors in my setup. This teaming feature seems to change mac-address often because of the balancing (alb), maybe pfSense or something is getting confused by this?





Log in to reply