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 DROPAlso 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 DROP1 Answer
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.
0
