[Solved] FreeBSD bridge problem

david_shur · #1 November 26th, 2010, 17:50

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.

aragon · #2 November 26th, 2010, 21:24

Are you setting em0 and em1 up?

david_shur · #3 November 27th, 2010, 01:06

Yes - setting them both up with ifconfig.

**DutchDaemon** · #4 November 27th, 2010, 01:09

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)

david_shur · #5 November 27th, 2010, 01:15

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

Code:

ifconfig em0 up
ifconfig em1 up

**DutchDaemon** · #6 November 27th, 2010, 01:25

Post the output of ifconfig -a if you will.

david_shur · #7 November 27th, 2010, 02:36

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

**DutchDaemon** · #8 November 27th, 2010, 02:49

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 · #9 November 27th, 2010, 03:16

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 · #10 November 27th, 2010, 03:22

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** · #11 November 27th, 2010, 03:46

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. kldstat -v | grep -i pf and disable pf/ipfw/pflog etc. before doing more tests. Just to get test results that are attributable to a single cause.

aragon · #12 November 27th, 2010, 14:16

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.

david_shur · #13 November 27th, 2010, 14:22

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 · #14 November 30th, 2010, 02:55

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 · #15 March 26th, 2011, 22:54

Quote:

Originally Posted by david_shur

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 · #16 July 24th, 2011, 10:04

Quote:

Originally Posted by DutchDaemon

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** · #17 July 24th, 2011, 23:33

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 · #18 July 25th, 2011, 16:31

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
FreeBSD 8 Wpa on Bridge	mih3y	Networking	0	March 4th, 2010 11:46
Bridge FreeBSD, PF and transparent squid	ozanus	Networking	2	January 25th, 2010 18:50
pppoe+adsl bridge+freebsd.	javid	Networking	3	June 9th, 2009 12:39
problem with bridge + ipfw	Aidaho	Firewalls	2	April 10th, 2009 09:50
Bridge networking to vm problem	tim-m89	Networking	0	April 8th, 2009 07:52

The Following User Says Thank You to DutchDaemon For This Useful Post:
mecano (July 24th, 2011)

The Following User Says Thank You to DutchDaemon For This Useful Post:
mecano (July 25th, 2011)