1

Situation:

Network A <-> Server <-> Client Host

I want to allow the client host to access network A via a bridge, allowing both hosts access to network A over one ethernet connection.

These are all physical devices, and I'm using Linux/Ubuntu machines.

So I created a bridge, ntlbridge0 and enslaved two of the ethernet devices on the Server to it, eth0 (to network A) and eth1 (to the client).

Both the Server and the Client are getting their IP addresses via DHCP. (which are assigned by Mac address by the router)

How am I supposed to set this connection up so that the Client can acquire a DHCP lease from the network?

While the client is trying to connect, it doesn't have an IP address yet, so I'm not sure how I can make a firewall rule to allow traffic from eth1 to eth0 without giving ufw/iptables an IP address to masquerade or forward to.

Ideally, I would like for both the Server and the Client to appear visible to network A at the same level. (Each should have their own IP, so network manager's 'Share Internet' won't work.) And the Client's MAC address should be visible to the network (so that it gets the correct IP from the router.

I had this working earlier (by means of which I am now unsure of), but now I can no longer get it to work even after I disable firewalls and re-create connections.

More details:

  • Using network-manager for all devices mentioned
  • UFW should stay enabled on both hosts for security
  • I'm using a patch cable between the server and client (does this still matter?)
  • All Server connections are working fine, and Client connects correctly when not being bridged through the server.

On the server:

route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.10.1    0.0.0.0         UG    426    0        0 ntlbridge0
192.168.10.0    *               255.255.255.0   U     425    0        0 ntlbridge0
192.168.10.0    *               255.255.255.0   U     426    0        0 ntlbridge0

nmcli dev status
DEVICE      TYPE      STATE      CONNECTION
ntlbridge0  bridge    connected  bridge ntl
enp1s0f0    ethernet  connected  ntlbridge0 slave enp1s0f0 
enp1s0f1    ethernet  connected  ntlbridge0 slave enp1s0f1

Further information requested:

ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0f0:  mtu 1500 qdisc mq master ntlbridge0 state UP mode DEFAULT group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff
3: enp1s0f1:  mtu 1500 qdisc mq master ntlbridge0 state UP mode DEFAULT group default qlen 1000
    link/ether d0:27:xx:xx:xx:41 brd ff:ff:ff:ff:ff:ff
9: ntlbridge0:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff

ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0f0:  mtu 1500 qdisc mq master ntlbridge0 state UP group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff
3: enp1s0f1:  mtu 1500 qdisc mq master ntlbridge0 state UP group default qlen 1000
    link/ether d0:27:xx:xx:xx:41 brd ff:ff:ff:ff:ff:ff
9: ntlbridge0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.67/24 brd 192.168.10.255 scope global dynamic ntlbridge0
       valid_lft 50187sec preferred_lft 50187sec
    inet6 2601:844:4000:xxx:xxx:xxxx:xxxx:ac61/64 scope global noprefixroute dynamic 
       valid_lft 2367sec preferred_lft 2367sec
    inet6 fe80::1e94:xxxx:xxxx:77ba/64 scope link 
       valid_lft forever preferred_lft forever

ip route show
default via 192.168.10.1 dev ntlbridge0  proto static  metric 425 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown 
192.168.10.0/24 dev ntlbridge0  proto kernel  scope link  src 192.168.10.67  metric 425 
192.168.10.0/24 dev ntlbridge0  proto kernel  scope link  src 192.168.10.67  metric 426 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 linkdown

brctl show
bridge name     bridge id       STP enabled interfaces
docker0         8000.0242910e3b7a   no      
ntlbridge0      8000.d027xxxxxx40   yes     enp1s0f0
                                enp1s0f1
Improve this question
6
  • You're using a bridge, which is layer 2, and happens to get an IP fo free, but you're reasoning like you're routing at level 3. Having the bridge set doesn't require any iptables rule for DHCP to work. Nor will those iptables rules affect much. You set twice the same route 192.168.10.0/24 to ntlbridge0 with a different metric for the 2nd command to "work". But the bridge doesn't care. If you want to firewall at the layer 2 level, then you need ebtables instead of iptables, or an interacting mix of both. I doubt ufw can be used successfully in this case, because it's just an iptables frontend.
    – A.B
    Oct 15, 2017 at 11:02
  • 1
    You should check a few things to debug it and give more informations. Give low level informations, not just nmcli (ip link show; ip addr show; ip route show; brctl show; iptables-save ) in case something is misconfigured (eg: a physical interface with an ip address). You could also run simultaneously two tcpdump commands on server, one on each port (even a 3rd on the bridge if needed), having at least the -e option , to verify that dhcp requests and answers are really seen and passed over the bridge both ways, or detect at which step it stops working.
    – A.B
    Oct 15, 2017 at 12:01
  • @A.B I've added that information to the post. I couldn't figure out where packets were being dropped using wireshark.
    – Robobenklein
    Oct 16, 2017 at 0:51
  • Second anomaly I can see (first being the useless duplicate route): 3: enp1s0f1: mtu 1500 qdisc mq master ntlbridge0 state DOWN group default qlen 1000 link/ether d0:27:xx:xx:xx:41 brd ff:ff:ff:ff:ff:ff . That is most likely the cause of the problems. tcpdump would have told you it couldn't capture on enp1s0f1. But I bet wireshark just didn't show enp1s0f1 at all. You really should use tcpdump at start.
    – A.B
    Oct 16, 2017 at 1:11
  • @A.B Whoops, alright that was an unrelated issue. Fixed that, but still can't get traffic across. I definitely am seeing activity in /var/log/ufw.log on the client's interface when trying to connect though... not sure if that's related.
    – Robobenklein
    Oct 16, 2017 at 1:13

1 Answer 1

Reset to default
3

Soooooooo here's the funny thing about bridging in modern kernels... you can tell the kernel to send packets that pass through the bridge through iptables, and they're treated exactly the same as if they were forwarded at layer 3. It is rare that you actually want this, and yet some distros or kernel versions or something turn that feature on by default (probably for security, which is understandable if frustrating).

Check the values of the sysctls /proc/sys/net/bridge/bridge-nf-call-*; if any of those are 1, then the corresponding filtering system is being used for matching packets (iptables for IPv4 packets, ip6tables for IPv6 packets). Set them to 0 to turn that thing off, and you may see a pleasant improvement.

There really isn't enough in your question to tell for sure that's what is going on, but the bridge-nf-call-* sysctls are always the first place I look when bridging is playing up.

Beyond that, without pcaps on all the interfaces involved, it's nearly impossible to tell what's going on and where the problem may lie.

Improve this answer
2
  • 1
    Amazing! I was so confused when I saw ufw activity with a bridge but now it makes sense seeing this, I'm surprised I haven't found this information elsewhere. Thanks!
    – Robobenklein
    Oct 18, 2017 at 3:05
  • Heh, wouldn't have found it, br_netfilter is no more loaded by default in recent kernels. Thanks for the information
    – A.B
    Oct 19, 2017 at 0:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.