Joined: 16 Jun 2006 Posts: 152 Location: Germany, BW
Posted: Mon Dec 01, 2008 9:51 Post subject:
sorry, have had not time over weekend to answer. I think you have to block the forwarding of the DHCP request.
iptables -I FORWARD 1 -i<WAN-Interface> -p UDP --sport 67:68 -j DROP
sorry, have had not time over weekend to answer. I think you have to block the forwarding of the DHCP request.
iptables -I FORWARD 1 -i<WAN-Interface> -p UDP --sport 67:68 -j DROP
No, not WAN-interface, but VPN-interface, it is across VPN that we do not want DHCP travel trough. WAN is diffirent thing...
Well I did link to an thread that has these commands already... And Also brainslayer added the correct module into source so now it is just as easy as start using the ebtables: http://svn.dd-wrt.com:8000/dd-wrt/changeset/11026
Are you saying, that with v24, all slgta and I need to do is to add the following code into our firewall script in both the VPN server and VPN client routers, and that there is no longer anything else to do to enable ebtables? (I pulled this code out of the thread linked to here and changed the interface to tap0.)
slgta, do you want to give this a try? I will not get to it this week due to other concerns. Be sure to upgrade your DD-WRT to the latest and include these in your startup script:
ok, I will give it a try.
One of the WRT54GL is in production at a remote site. So I might not be able to get to it until late of the week.
Will report with the result.
JN wrote:
slgta, do you want to give this a try? I will not get to it this week due to other concerns. Be sure to upgrade your DD-WRT to the latest and include these in your startup script:
Posted: Thu Dec 04, 2008 20:11 Post subject: It seems to be working
It seems to be working with the following added to the startup script ...
insmod ebtables
insmod ebtable_filter
insmod ebt_ip.o
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
It has been running for couple days now, and I have not seen devices getting DHCP IP across the VPN tunnel.
Will report back if I see any problem down the road.
BTW, I only did this on the VPN Server router. I could have done it at the client router too, but since I found another bug (ticket#759) of the client GUI ... will try it when EKO/BS have that bug fixed in the next build (hopefully). _________________ =============================================
WRT54GL v1.1 vpn-jffs-small SVN15200M
Spare: WRT54G v5 micro+ ssh SVN15200M
Posted: Fri Dec 05, 2008 18:48 Post subject: Re: It seems to be working
Updates ....
It didn't work. I have seem my laptop grabbing an DHCP IP from the remote router today.
I am now trying to put the ebtables statements in the firewall startup ... and leave the insmod statements in the regular startup. I am not sure what's the difference doing it this way, but I am running out of ideas.
Will report back after a few days.
slgta wrote:
It seems to be working with the following added to the startup script ...
insmod ebtables
insmod ebtable_filter
insmod ebt_ip.o
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
It has been running for couple days now, and I have not seen devices getting DHCP IP across the VPN tunnel.
Will report back if I see any problem down the road.
BTW, I only did this on the VPN Server router. I could have done it at the client router too, but since I found another bug (ticket#759) of the client GUI ... will try it when EKO/BS have that bug fixed in the next build (hopefully).
Posted: Sat Dec 06, 2008 18:28 Post subject: Re: It seems to be working
slgta wrote:
Updates ....
It didn't work. I have seem my laptop grabbing an DHCP IP from the remote router today.
I am now trying to put the ebtables statements in the firewall startup ... and leave the insmod statements in the regular startup. I am not sure what's the difference doing it this way, but I am running out of ideas.
Will report back after a few days.
slgta wrote:
It seems to be working with the following added to the startup script ...
insmod ebtables
insmod ebtable_filter
insmod ebt_ip.o
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
It has been running for couple days now, and I have not seen devices getting DHCP IP across the VPN tunnel.
Will report back if I see any problem down the road.
BTW, I only did this on the VPN Server router. I could have done it at the client router too, but since I found another bug (ticket#759) of the client GUI ... will try it when EKO/BS have that bug fixed in the next build (hopefully).
Thanks for letting us know. I was going to put the two ebtables lines in the firewall script when I got to it, but havn't had time. Let us all know how its working out.
Posted: Thu Dec 11, 2008 1:45 Post subject: Re: It seems to be working
slgta wrote:
Updates ....
It didn't work. I have seem my laptop grabbing an DHCP IP from the remote router today.
I am now trying to put the ebtables statements in the firewall startup ... and leave the insmod statements in the regular startup. I am not sure what's the difference doing it this way, but I am running out of ideas.
I tried updating both client and server VPN routers to 11100 and put the 3 ebtables startup commands in the startup script and the two ebtables rules in the firewall as discussed above and find they do not help one bit. About the second time I connected a computer to the client VPN router via DHCP, I received my IP address from the remote (main) router.
Well if someone has time and means to do some testing we could determine correct ebtables stuff once and for all...
One could disable DHCP from one router and try these blocking instructions on, well, basically on both routers... (output for DHCP enabled router and incoming for DHCP disabled router)This way we could find out what actually works and what not...
This is what I found on OpwnWRT forum thread:
Code:
ebtables -A INPUT --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
So I'd still say copy exactly that and change vlan0 to tap0... But again I can't test anything until after few weeks when I have moved out and starting to build 2 site VPN again...
ADD: Also to determine if firewallscript isn't enough, one could just manually type these commands after everything is otherwise working already. Then if these work add firwall script and reboot and then test again... This way we know is firewallscript enough or do we need to run these after VPN established etc... (maybe devs would add yet another input for "run this after vpn is up")
ebtables -A INPUT --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface vlan0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
So I'd still say copy exactly that and change vlan0 to tap0... But again I can't test anything until after few weeks when I have moved out and starting to build 2 site VPN again...
I tried these (changing vlan0 to tap0 and they did not seem to do anything. I had them in both client and server routers running vpn standard build 11100. I had to give up the extra internet connection, so I will not be able to test easily. I hope someone can help finish resolving this issue.