1

I have a linux bridge machine bridging tap0, tap1 (2 networks) together into a br0. I would like to stop only the dhcp traffic between the 2 bridge endpoints.

I have tried everything with ebtables but has no effect:

Bridge table: filter

Bridge chain: INPUT, entries: 4, policy: ACCEPT
-p IPv4 -i tap0+ --ip-proto udp --ip-dport 67:68 -j DROP 
-p IPv4 -i tap0+ --ip-proto udp --ip-sport 67:68 -j DROP 
-p IPv4 -i tap1+ --ip-proto udp --ip-dport 67:68 -j DROP 
-p IPv4 -i tap1+ --ip-proto udp --ip-sport 67:68 -j DROP 

Bridge chain: FORWARD, entries: 10, policy: ACCEPT
-p IPv4 -o tap0+ --ip-proto udp --ip-dport 67:68 -j DROP 
-p IPv4 -o tap0+ --ip-proto udp --ip-sport 67:68 -j DROP 
-p IPv4 -o tap1+ --ip-proto udp --ip-dport 67:68 -j DROP 
-p IPv4 -o tap1+ --ip-proto udp --ip-sport 67:68 -j DROP 
-d Broadcast -i tap1 -j DROP 
-d Broadcast -i tap0 -j DROP 
-s Broadcast -i tap0 -j DROP 
-s Broadcast -i tap1 -j DROP 
-s Broadcast -o tap0 -j DROP 
-s Broadcast -o tap1 -j DROP 

Bridge chain: OUTPUT, entries: 4, policy: ACCEPT
-p IPv4 -o tap0+ --ip-proto udp --ip-dport 67:68 -j DROP 
-p IPv4 -o tap0+ --ip-proto udp --ip-sport 67:68 -j DROP 
-p IPv4 -o tap1+ --ip-proto udp --ip-dport 67:68 -j DROP 
-p IPv4 -o tap1+ --ip-proto udp --ip-sport 67:68 -j DROP
pinky
  • 11
  • 1
  • Which kind of network would require such a thing? To me the network design looks broken, and such filtering should not happen. If you have two different IP subnetworks bridged together, that will cause all kinds of problems in the long run and cannot work reliably. – Tero Kilkanen Sep 01 '16 at 20:22
  • That was not the question, it has to be setup like that. What is the reason behind all this is not blocking the raw ip dhcp packets which sent to the bcast. If I block the bcast traffic for example the communication between the 2 networks will split up since hosts on netA cannot arp resolve hosts on netB anymore (however if its cached in the arp table then they can communicate.). It's besides the point, even then the DHCP traffic just keep going through and I would like to know why. – pinky Sep 02 '16 at 09:52
  • I've run into this exact situation and was looking for insight into whether the solution we have in place is the right one. We used `ebtables -A FORWARD -s AB:CD:01:02:03:04 -j DROP` where 'AB:CD:01:02:03:04' is the mac address of the machine handing out DHCP on the outside network. It seems to be working and is stable but has to be manually entered on each machine in the cluster. – Jarad Downing May 24 '21 at 17:05

0 Answers0