Posted: Thu Oct 05, 2006 16:04 Post subject: Which table use ebtables in DD-WRT vpn v23 SP2?
Hi, I'm writing because I'm trying to use ebtables to block DHCP traffic between two WRT54GL (with DD-WRT vpn v23 SP2 both of them) that are running OpenVPN in bridged mode (one router as server the other as client). The reason why I'm trying to block the DHCP traffic it's because once that the two routers are connected by OpenVPN and because they are at bridged mode, the subnet built between them has 2 DHCP server, but each DHCP server has to give IP information only to clients physically (wired or wireless) connected to the router, and with the VPN tunnel build one DHCP server can give IP information to a client connected to the router in the other side of the tunnel.
I tried to use iptables to block this using this sentence:
iptables -I INPUT -i tap0 --dport bootps -j DROP
but it didn't work. I think it didn't work because before executing openvpn I had to bridge tap0 to br0 as if it was another ethernet port in the router, so tap0 won't have an IP, so iptables won't work over that interface, it would work over br0 which is the interface that has the IP, but if I block bootps over br0 I would block DHCP coming from the VPN tunnel and also the connections from clients physically connected to the router.
Joined: 04 Nov 2006 Posts: 89 Location: The Dalles, Oregon USA
Posted: Tue Dec 26, 2006 2:33 Post subject:
Hey guys--
Allright, i just figured this deal out:
Ah-hah-- I see-- it seems that ebt_ip is needed, and it is not included in the standard (asus in my case) install under /lib/modules/2.4.34-pre2/, which appears to be where the modules are pulled from. If you have done the ipkg install ebtables, you will have ebt_ip.o in /jffs/lib/modules/2.4.30 -- and you (apprently) can insmod it using the absolute path. Here is my output from walking through it:
Joined: 07 Jun 2006 Posts: 1488 Location: the Netherlands
Posted: Tue Mar 13, 2007 17:44 Post subject:
Sorry about the kick, but any luck on this? Cause I'm having the exact same issue here.
It should be able to run from a startup script and still allow dhcp requests from other clients but one.
[edit]
After using insmod etc I got the folowing:
Code:
~ # ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
~ # ebtables -I INPUT -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension.
_________________ Firmware: DD-WRT v24-sp2 (latest available) mega
WRT320N
Or is there another way to stop dhcp through the VPN since iptables won't work cause they only work between WAN and LAN (I was told to). _________________ Firmware: DD-WRT v24-sp2 (latest available) mega
WRT320N
Joined: 04 Nov 2006 Posts: 89 Location: The Dalles, Oregon USA
Posted: Tue Mar 13, 2007 20:07 Post subject:
This is EBtables, not IPTables. It is for bridges... which is why you need it.
This will work to stop dhcp over a bridge, i've used it successfully.
I see that the ebt_ip module isn't loaded on your lsmod list. It may be possible that it needs to be loaded. (not for sure, its been a while since i did this.)
Joined: 07 Jun 2006 Posts: 1488 Location: the Netherlands
Posted: Tue Mar 13, 2007 20:22 Post subject:
True, that's not inserted indeed, where can I find that module? Since it's not included with DD-WRT by default _________________ Firmware: DD-WRT v24-sp2 (latest available) mega
WRT320N
Posted: Tue Mar 29, 2011 18:55 Post subject: Nothing short of ingenious, BUT......
Well, it works. Sort of. Unfortunately, in my implementation, it seems to break the bridge entirely. I have tried it as provided, and also with INPUT -i changed to OUTPUT -o and nothing seems to work. The bridge is not working at all now.
I speculate that what is happening is that the DHCP for the remote box is getting eaten as well, so it never connects. Perhaps tonight I will see what happens if I leave it as INPUT -i and put it on the remote box. Perhaps that would at least keep the main location from getting the remote gateway.
Sigh...this is a very frustrating problem. Why hasn't a permanent fix for this been implemented into the OpenVPN code? Or has it? I am running some older firmware (2009). Do I need to update it and hope nothing else breaks? I hate to do that because it is working perfectly aside from this one issue. If it ain't broke, don't fix it, right?
THIS is the solution that finally seems to work with no problems for me. I have been fooling around with this for literally YEARS looking for the correct solution to this problem. Now I am sure I have found it. MUCH THANKS to the creator of the CRON job that fixes this frustrating problem!
EDIT: As he says, DO VERIFY THE FILE PATHS. I had to change .37 to .36 because I'm using a slightly older DD-WRT and I refuse to change because everything is working perfectly as-is.
