Very strange bridging issue (LAN-WiFi)



  • Hi All,

    I have a very strange bridging issue I cannot wrap my head around.  I'm running 2.2.5.

    I have two physical interfaces, let's call them LAN and WIFI.  LAN and WIFI are put into BRIDGE1.  For reference, the system tunables with regards to Bridges are set as follows.

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

    And another reference, there are two more NICs which are WAN and DMZ which are BRIDGE0 (That's working perfectly great).

    Anyway, continuing on, Pass rules for all IPv4/IPv6 traffic from anywhere to anywhere are inserted at the very top for LAN, WIFI, and BRIDGE1.  Here is where it gets weird:

    WIFI IP traffic NAT's out fine.
    WIFI IP traffic gets to LAN segment fine.
    LAN IP traffic NAT's out fine.
    LAN IP traffic cannot get to WIFI segment but non-IP traffic looks fine (i.e. ARP) and LAN ARP traffic originating from the LAN segment shows up on both the BRIDGE1 & WIFI interface.

    This is where it begins to get strange.  I can see ARP traffic just fine on the LAN interface from devices on the WIFI side.  But if I initiate an ICMP ping from a machine on the LAN segment to a device on the WIFI segment, I see the ICMP traffic just fine on both the LAN and BRIDGE1 (using tcpdump to monitor), but I never see it bridged over to the WIFI segment.  And if I initiate an ICMP ping from a machine on the WIFI segment to a device on the LAN segment, it works perfectly fine.  And I can access IP-based services from a machine on WIFI to a machine on the LAN.  In other words, in reverse, WIFI to LAN, works perfectly.

    I double and triple checked I didn't mess up some Pass rules with each interface; It's wide open.

    So the question is, if there are other scenarios would cause IP traffic not making it from BRIDGE1 onto WIFI, which WIFI is a member of? But ARP traffic and other non-IP traffic bridge fine?

    Thanks in advance for any hints, tips & help.

    Cheers,
    Kermee


  • Banned

    @Kermee:

    I have two physical interfaces, let's call them LAN and WIFI.  LAN and WIFI are put into BRIDGE1.  For reference, the system tunables with regards to Bridges are set as follows.

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

    And another reference, there are two more NICs which are WAN and DMZ which are BRIDGE0 (That's working perfectly great).

    And why are you filtering BOTH the bridge and the members? Sigh. You might want to fix the thread subject, like "Very strange bridging setup".



  • @doktornotor:

    And why are you filtering BOTH the bridge and the members? Sigh. You might want to fix the thread subject, like "Very strange bridging setup".

    Hi doktornotor,

    Thanks for the tip. I read up a little bit and apologize. Still a bit of a n00b. I found this thread:

    https://forum.pfsense.org/index.php?topic=100911.0

    So I've turned off packet filtering on the actual bridge itself and would like to continue to manage them at the member level.  I've de-assigned an interface to the bridge.  That way I can still apply rules from both sides of the transparent bridge at the members.

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

    As as I understand it with net.link.bridge.pfil_bridge=0, there should be no packet filtering done at all the bridge level. I'm experiencing the same behavior.  Just a quick note, the IPs on both the LAN and WIFI are RFC1918 private subnets and I've made sure "Block private networks" is unchecked on each member interface.

    But for quick check, I turned off packet filtering on both bridge & member, and the LAN side can reach the WIFI side. As soon as I turn pfil_member=1 back on and apply, the ICMP traffic/replies stop again from LAN to a device on the WIFI side.

    I ran pfctl -sr on each member to see if I'm blocking anything either way:

    WIFI (em0)

    pass in quick on em0 inet all flags S/SA keep state label "USER_RULE: Allow all IPv4/IPv6 traffic"
    pass in quick on em0 inet6 all flags S/SA keep state label "USER_RULE: Allow all IPv4/IPv6 traffic"
    

    LAN (em4)

    pass in quick on em4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
    pass in quick on em4 inet proto udp from any port = bootpc to 192.168.X.X port = bootps keep state label "allow access to DHCP server"
    pass out quick on em4 inet proto udp from 192.168.X.X port = bootps to any port = bootpc keep state label "allow access to DHCP server"
    pass in quick on em4 proto tcp from any to (em4) port = 8080 flags S/SA keep state label "anti-lockout rule"
    pass in quick on em4 proto tcp from any to (em4) port = http flags S/SA keep state label "anti-lockout rule"
    pass in quick on em4 proto tcp from any to (em4) port = ssh flags S/SA keep state label "anti-lockout rule"
    pass in quick on em4 inet all flags S/SA keep state label "USER_RULE: Allow all IPv4/IPv6 traffic"
    pass in quick on em4 inet6 all flags S/SA keep state label "USER_RULE: Allow all IPv4/IPv6 traffic"
    

    Anyway, thanks in advance for any help.  I'd like to keep packet filtering at the member level instead of the bridge level because I have some fairly custom Firewall rules for the WAN/DMZ bridge which wouldn't work at the bridge level.

    Cheers,
    Kermee


  • Banned

    @Kermee:

    So I've turned off packet filtering on the actual bridge itself and would like to continue to manage them at the member level.  I've de-assigned an interface to the bridge.  That way I can still apply rules from both sides of the transparent bridge at the members.

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

    Oh noes! Either filter the bridge, or stop bridging. Sigh again. What's the goal here?

    P.S. Bridging wireless and wired is generally a retarded idea.


Log in to reply