How to stop dhcp traffic via openvpn bridge?

1

In may case I have two openwrt routers connected with openvpn bridge.

Traffic can stoped by iptables with iptables-mod-extra:

iptables -I FORWARD -m physdev --physdev-out tap0 -p udp --dport 67:68 -j DROP
iptables -I FORWARD -m physdev --physdev-in tap0 -p udp --dport 67:68 -j DROP
iptables -I INPUT -m physdev --physdev-in tap0 -p udp --dport 67:68 -j DROP

Also traffic can be stoped by ebtables:

ebtables -I FORWARD -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP 
ebtables -I FORWARD -o tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP 
ebtables -I INPUT -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP 
ebtables -I OUTPUT -o tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP

5f0f5

Posted 2016-11-03T13:51:16.057

Reputation: 113

If I understand correctly, you're trying to have two DHCP servers in one broadcast domain with a VPN bridge connecting two parts of it. You want to block DHCP traffic through the bridge. Can you explain why you want two DHCP servers and not just one - perhaps with a backup on the other side? And why to use a bridge and not routing (tun)? Did you try to inspect what is going on with tcpdump or similar? – Zrin – 2016-11-03T14:06:26.533

check the routing table on the Macbook after "1)", "2)" and "3)", try to ping 10.0.0.1, 10.0.0.5 and other devices from the Macbook while watching tcpdump output on both routers - check tcpdump man page... This should help you find the cause. – Zrin – 2016-11-03T15:43:25.750

good, now you have the cause - the answer to ARP "Who has 10.0.0.5?" doesn't get back to the Mac. Perhaps due to some cache? What happens if you try few minutes later? Also check if the same happens with other devices, besides that Macbook. – Zrin – 2016-11-07T07:21:46.623

Good, you've found that the ARP reply from 10.0.0.5 does not get back to 10.0.0.1. That is the probable cause of the problem. 10.0.0.5 is sending that ARP replies to a wrong interface, probably because it "learned" before that the device (the Macbook) was connected to the other interface (Wi-Fi) before - and hasn't forget it (yet), nor has it updated internal tables when the ARP request with the Macbook's MAC address arrived through the VPN tunnel / through the associated TAP interface. I suggest that you edit your question and add your observations gained with tcpdump and ARP packets. – Zrin – 2016-11-08T09:07:44.770

Answers

2

Your setup regarding the VPN bridge and DHCP separation is correct.

The problem is (most probably) within your second AP / router "10.0.0.5" that internally remembers (for too long?) that a device was connected to its Wi-Fi interface and that does not update this information when packets with the same MAC address come from another interface, in your case the VPN tunnel's TAP interface.

Connected to "10.0.0.1" again, your device ("Macbook") sends ARP requests "Who has 10.0.0.5" which go through the VPN tunnel to "10.0.0.5", but which don't get answered or don't get forwarded to the correct (now TAP) interface.

You need to check how the VPN TAP interface is bridged within the AP / router, if the bridge setup is appropriate for your configuration.

I suggest that you repeat your tests and capture tcpdump logs on interfaces in question, also internal bridge and / with Wi-Fi interface(s) to see where the ARP replies go, and then open a new question with appropriate tags regarding this possibly specific problem with your AP / router.

Zrin

Posted 2016-11-03T13:51:16.057

Reputation: 146

Asked: 2016-11-03T13:51:16.057

Viewed: 911 times

Active: 2016-11-10T18:38:29.273