FreeBSD bridge problem

D

david_shur

Hi, I am trying to get bridging to work on a two interface system using the following commands:

Code: 
ifconfig bridge create
ifconfig bridge0 addm em0 addm em1 up           #interface names are em0 and em1

The problem is the bridge passes arp requests, but not arp replies.

I have tried this this with 8.1 stable, and also Frenzy 1.1 and 1.3 all with the same result. What simple thing am I missing?

Thanks,
David.
 
Before or after the bridge is set up? Should be after. In terms of /etc/rc.conf it's usually something like this:

Code: 
cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm em1 up"
ifconfig_em0="up" (can also be IP/netmask declaration)
ifconfig_em1="up" (idem)
 
After the bridge is set up. I am doing it manually from the shell.
ie,
Code: 
ifconfig em0 up
ifconfig em1 up
 
I see you have pflog0. Does that mean you're filtering on the bridge or its members with pf? Use tcpdump(1) on the bridge and both interfaces to see where traffic flow stops exactly. If you are filtering, you may have to set a skip rule somewhere (maybe on bridge0).
 
The topology is:

a<->b<->c

where b is the bridge, with interfaces em0 pointing to a, and em1 pointing to c.
b also has bridge interface bridge0
a has ip address 10.1.1.1 netmask 255.255.255.0 and b has ip address 10.1.1.2 netmask 255.255.255.0

When I ping from 10.1.1.1 (a) to 10.1.1.2 (c), the arp request goes from a to b to c. c responds with an arp reply. however none of b's interfaces (em1, bridge0, em0) see the arp reply - yet they all see the arp request. When I reversed the test ( ie ping from c to a) I got a similar result, namely, a's arp reply was not seen at b.

I am not explicitly using pf. I am not familiar with it. However the web site I was looking at was giving a recipe to use ipfw/dummynet in a bridge config, which is also my goal. But I have not yet got the bridge part working, so the ipfw rules are also not being used (beyond the a default which allows ip from any to any.
 
Sorry typo - not
a has ip address 10.1.1.1 netmask 255.255.255.0 and b has ip address 10.1.1.2 netmask 255.255.255.0
but
a has ip address 10.1.1.1 netmask 255.255.255.0 and c has ip address 10.1.1.2 netmask 255.255.255.0
 
I advise you to make absolutely sure that no package filter (pf, ipfw) is active in any way before the bridge part is actually proven to work at its most basic level (arp, icmp). Check e.g.[cmd=]kldstat -v | grep -i pf[/cmd] and disable pf/ipfw/pflog etc. before doing more tests. Just to get test results that are attributable to a single cause.
 
Perhaps also setup these sysctls to ensure bridge traffic doesn't hit a packet filter:

Code: 
net.link.bridge.pfil_member=0
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0

Even if just to test. :)
 
Thanks for all the replies. I am making progress. I have it working now on VMware VMs. :) Problem was the default security settings on the VMs prevented MAC address substitution. When I get back to my office, I will try it and make it work on a physical machine. Will post on my progress.

Thanks,
David.
 
Bridge (and dummynet) works fine on my dell laptop. The problem was with the virtual machines, which has been fixed as posted previously. Thanks again for the help.
 
DutchDaemon said:
I see you have pflog0. Does that mean you're filtering on the bridge or its members with pf? Use tcpdump(1) on the bridge and both interfaces to see where traffic flow stops exactly. If you are filtering, you may have to set a skip rule somewhere (maybe on bridge0).
Click to expand...

DD, just to be sure I'm on the right track, in case of "IP replication" (where em0 has IP/netmask and em1 has just been "up"ed) wouldn't it be easier to filter bridge0 and skip on em0, em1 to avoid jabbers in pf.conf?
 
It depends on where your traffic originates and where you want to stop unwanted traffic, and which interface local services (on the firewall, like a DNS resolver) are bound to. E.g. you might want to shield some services on the server from your LAN, but not your WAN, or vice versa. One usually blocks closest to the side one wants to defend. If there are no local services whatsoever on the firewall (it is a pure bridge), one might as well filter on bridge0 and leave em0/1 skip'ed.
 
Thanks DD! I wanted to be sure there wasn't any pitfall by skipping real interfaces.
Yes I'm thinking about DNS resolver and specific lan/wan filtering later to harden things (because transparent bridge firewalling is not an option here).
 
Hi guys!

After upgrade to the most recent version of FreeBSD 10.0-STABLE #5 r269851 my bridge interface stopped to response to USB Ethernet network cards!
It works with the normal ethernet cards without any problems, but for the docking stations like this http://www.amazon.com/gp/product/B00ECD ... UTF8&psc=1 it doesn't work.

On the server side I can see the following activity
Code: 
# tcpdump -ni bridge0 ether host 00:50:b6:11:18:c1
16:12:28.653784 ARP, Request who-has 192.168.20.1 tell 192.168.22.206, length 50
16:12:28.653789 ARP, Reply 192.168.20.1 is-at 02:06:3d:ee:b0:00, length 32
But on the client side the ARP Reply doesn't exist.

Changes of thee values are not affecting anything.
Code: 
net.link.bridge.pfil_onlyip=0
net.link.bridge.pfil_member=0
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0
I using PF, but the only rule I have for the bridge is
Code: 
pass quick on bridge0 all no state
It worked well with this version FreeBSD 10.0-STABLE #0 r261326.

The bridge itself looks like
Code: 
# ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 02:06:3d:ee:b0:00
	inet 192.168.20.1 netmask 0xfffffc00 broadcast 192.168.23.255 
	nd6 options=9<PERFORMNUD,IFDISABLED>
	id 00:25:90:d6:c2:c8 priority 32768 hellotime 2 fwddelay 15
	maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
	root id 00:22:3f:f4:fb:d3 priority 32768 ifcost 2000000 port 3
	member: lan2 flags=147<LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP>
	        ifmaxaddr 0 port 6 priority 128 path cost 2000000 proto rstp
	        role disabled state discarding
	member: lan1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
	        ifmaxaddr 0 port 5 priority 128 path cost 2000000 proto rstp
	        role designated state forwarding
	member: lan0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
	        ifmaxaddr 0 port 3 priority 128 path cost 2000000 proto rstp
	        role root state forwarding
	member: wlan0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
	        ifmaxaddr 0 port 4 priority 128 path cost 2000000 proto rstp
	        role designated state forwarding
I will appreciate any suggestions.

Thank you,
Vagif

UPDATE: It seems like there is something wrong with the DisplayLink Ethernet Windows drivers, because it perfectly works with Mac. But anyway, why it worked with the older FreeBSD version? What is there something I can do on the server side?
 
You must log in or register to reply here.
Back
Top