# FreeBSD bridge problem



## david_shur (Nov 26, 2010)

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


```
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.


----------



## aragon (Nov 26, 2010)

Are you setting em0 and em1 up?


----------



## david_shur (Nov 27, 2010)

Yes -  setting them both up with ifconfig.


----------



## DutchDaemon (Nov 27, 2010)

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


```
cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm em1 up"
ifconfig_em0="up" (can also be IP/netmask declaration)
ifconfig_em1="up" (idem)
```


----------



## david_shur (Nov 27, 2010)

After the bridge is set up. I am doing it manually from the shell. 
ie, 

```
ifconfig em0 up
ifconfig em1 up
```


----------



## DutchDaemon (Nov 27, 2010)

Post the output of [cmd=]ifconfig -a[/cmd] if you will.


----------



## david_shur (Nov 27, 2010)

Output of "ifconfig -a" attached in zip file. Thanks.


----------



## DutchDaemon (Nov 27, 2010)

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).


----------



## david_shur (Nov 27, 2010)

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.


----------



## david_shur (Nov 27, 2010)

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


----------



## DutchDaemon (Nov 27, 2010)

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.


----------



## aragon (Nov 27, 2010)

Perhaps also setup these sysctls to ensure bridge traffic doesn't hit a packet filter:


```
net.link.bridge.pfil_member=0
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0
```

Even if just to test.


----------



## david_shur (Nov 27, 2010)

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.


----------



## david_shur (Nov 30, 2010)

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.


----------



## dcorsello (Mar 26, 2011)

david_shur said:
			
		

> Problem was the default security settings on the VMs prevented MAC address substitution.



Did you get this to work in your VMs?  If so, how?


----------



## mecano (Jul 24, 2011)

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).



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?


----------



## DutchDaemon (Jul 24, 2011)

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.


----------



## mecano (Jul 25, 2011)

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).


----------



## vagifzeynalov (Aug 13, 2014)

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

```
# 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.

```
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

```
pass quick on bridge0 all no state
```
It worked well with this version FreeBSD 10.0-STABLE #0 r261326.

The bridge itself looks like

```
# 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?


----------

