Clients on a bridged lan can't see each other?



  • here's my setup

    (em0 WAN) –- pfsense --- (em1, em2, em3)

    Bridge interface BRIDGE0 --- Members LAN, OPT1, OPT2, OPT3

    pfsense interface - network Port
    WAN - em0
    LAN - BRIDGE0
    OPT1 - em1
    OPT2 - em2
    OPT3 - em3

    OPT1,OPT2,OPT3 configured as ipv4 NONE and ipv6 NONE.
    LAN configured as static 192.168.1.1
    DHCP server configured on LAN.

    System tunables net.link.bridge.pfil_member set to 0, net.link.bridge.pfil_bridge set to 1.

    Now,
    client 1 connects physically to em1 via ethernet, receives IP address 192.168.1.101
    client 2 connects physically to em1 via ethernet, received IP address 192.168.1.102
    client 1 and client 2 can connect to each other.

    However,
    client 1 connects physically to em1 via ethernet, receives IP address 192.168.1.101
    client 2 connects physically to em2 via ethernet, receives IP address 192.168.1.102

    however, now client1 and client2 can NOT see each other .

    Why is this happening? Any ideas? If the 2 machines are connected via the same network port they can ping each other, but if they are connected via different network ports (on the same bridge) they can't.



  • Why would you bridge multiple LAN interfaces? That is exactly what a switch is for. pfSense is a firewall and a router, not a switch.



  • Well, i figured the functionality was there and the hardware was there, so I didn't have to go buy a new switch. Sure, I could simply buy a switch, connect it to em1, leave em2 and em3 alone and connect everything I wanted to the switch but …. so I shouldn't be using pfsense this way?



  • OPTx by default doesnt have any rules to do anything, so you need to create allow rules.

    Best to set all rules to log including the block/reject rules so you can see whats getting through and whats not in the firewall log.

    Personally I'd not bridge the way you have as you can isolate traffic more with things like snort using custom rules & schedules along with various fw rules a little better and dhcp on each OPTx interface.

    One example might be you want the users plugged into OPT1 & OPT2 to have unrestricted net access, but OPT3 might only have access to say financial websites. Plus its easier to expand the network by plugging switches into each OPTx interface if its a business that might grow in time. Ultimately it depends on your situ and how that might change in the future.


  • Banned

    @firewalluser:

    OPTx by default doesnt have any rules to do anything, so you need to create allow rules.

    Please, read this again.

    System tunables net.link.bridge.pfil_member set to 0, net.link.bridge.pfil_bridge set to 1.

    No idea where do rules on OPTx come into play here.

    @OP:  This… Do yourself a big favour and get the damned switch.



  • @doktornotor:

    No idea where do rules on OPTx come into play here.

    This line should have been 1st, then it would make more sense.
    Personally I'd not bridge the way you have as you can isolate traffic more with things like snort using custom rules & schedules along with various fw rules a little better and dhcp on each OPTx interface

    In answer to your question, its because of the bridge problem, which you mentioned to the OP.

    Of course this might help as others have reported things not working properly since freebsd 9, that might explain why bridges are a pain, bit like the states not working as expected.
    https://www.mail-archive.com/freebsd-pf@freebsd.org/msg05983.html

    Edfit. Might also be useful. http://home.nuug.no/~peter/pf/newest/bridge-freebsd.html