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 - em3OPT1,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.102however, 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.
-
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.
-
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 interfaceIn 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.htmlEdfit. Might also be useful. http://home.nuug.no/~peter/pf/newest/bridge-freebsd.html