Bridged VPN, using iptables to fix DHCP issue?

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3, 4  Next
Author Message
Sp1derman
DD-WRT Novice


Joined: 16 Jun 2006
Posts: 42

PostPosted: Mon Dec 01, 2008 9:51    Post subject: Reply with quote
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
Sponsor
olmari
DD-WRT Guru


Joined: 24 Oct 2006
Posts: 1447
Location: Vaasa, Finland

PostPosted: Mon Dec 01, 2008 12:28    Post subject: Reply with quote
Sp1derman wrote:
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...

_________________
Site 1:
P3 1GHz Coppermine with DD-WRT v24 as main router
2x Buffalo WHR-HP-G54 with DD-WRT v24 as AP

Site 2:
AMD64 4200+ Dualcore AM2 with DD-WRT v24 as main router
Buffalo WHR-HP-G54 with DD-WRT v24 as AP
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Mon Dec 01, 2008 14:27    Post subject: Reply with quote
JN wrote:
olmari wrote:
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.)

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
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:

insmod ebtables
insmod ebtable_filter
insmod ebt_ip.o
slgta
DD-WRT User


Joined: 09 Jan 2008
Posts: 92

PostPosted: Mon Dec 01, 2008 15:31    Post subject: Reply with quote
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:

insmod ebtables
insmod ebtable_filter
insmod ebt_ip.o

_________________
=============================================
WRT54GL v1.1 vpn-jffs-small SVN15200M
Spare: WRT54G v5 micro+ ssh SVN15200M
slgta
DD-WRT User


Joined: 09 Jan 2008
Posts: 92

PostPosted: Thu Dec 04, 2008 20:11    Post subject: It seems to be working Reply with quote
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
jgombos
DD-WRT User


Joined: 03 Nov 2007
Posts: 68

PostPosted: Fri Dec 05, 2008 8:47    Post subject: Reply with quote
JN wrote:

...
# Set some important values:
nvram set wl0.1_ipaddr=192.168.2.1
nvram set wl0.1_netmask=255.255.255.0
...

Looks like you're missing an "nvram commit"; otherwise those parameters won't get saved.
olmari
DD-WRT Guru


Joined: 24 Oct 2006
Posts: 1447
Location: Vaasa, Finland

PostPosted: Fri Dec 05, 2008 11:12    Post subject: Reply with quote
jgombos wrote:
JN wrote:

...
# Set some important values:
nvram set wl0.1_ipaddr=192.168.2.1
nvram set wl0.1_netmask=255.255.255.0
...

Looks like you're missing an "nvram commit"; otherwise those parameters won't get saved.


No need to commit them, they are created/changed on every startup thus not needed to commit them.

_________________
Site 1:
P3 1GHz Coppermine with DD-WRT v24 as main router
2x Buffalo WHR-HP-G54 with DD-WRT v24 as AP

Site 2:
AMD64 4200+ Dualcore AM2 with DD-WRT v24 as main router
Buffalo WHR-HP-G54 with DD-WRT v24 as AP
slgta
DD-WRT User


Joined: 09 Jan 2008
Posts: 92

PostPosted: Fri Dec 05, 2008 18:48    Post subject: Re: It seems to be working Reply with quote
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).

_________________
=============================================
WRT54GL v1.1 vpn-jffs-small SVN15200M
Spare: WRT54G v5 micro+ ssh SVN15200M
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Sat Dec 06, 2008 18:28    Post subject: Re: It seems to be working Reply with quote
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.
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Thu Dec 11, 2008 1:45    Post subject: Re: It seems to be working Reply with quote
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.
How's it going slgta with your latest change?
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Fri Dec 12, 2008 1:11    Post subject: Reply with quote
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.

Can someone please help?

Thanks
olmari
DD-WRT Guru


Joined: 24 Oct 2006
Posts: 1447
Location: Vaasa, Finland

PostPosted: Fri Dec 12, 2008 1:35    Post subject: Reply with quote
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")

_________________
Site 1:
P3 1GHz Coppermine with DD-WRT v24 as main router
2x Buffalo WHR-HP-G54 with DD-WRT v24 as AP

Site 2:
AMD64 4200+ Dualcore AM2 with DD-WRT v24 as main router
Buffalo WHR-HP-G54 with DD-WRT v24 as AP
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Tue Dec 16, 2008 21:48    Post subject: Reply with quote
olmari wrote:

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...
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.
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Thu Dec 18, 2008 3:54    Post subject: Reply with quote
bump
JN
DD-WRT Guru


Joined: 29 Mar 2007
Posts: 754

PostPosted: Sat Dec 20, 2008 21:37    Post subject: Reply with quote
slgta, or anyone else, have you made any headway with this?
Goto page Previous  1, 2, 3, 4  Next Display posts from previous:    Page 2 of 4
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum