Site to site VPN 2 DD-WRT routers, route internet thru VPN?

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
tkoyn
DD-WRT User


Joined: 11 Feb 2007
Posts: 442

PostPosted: Thu Aug 16, 2018 4:26    Post subject: Site to site VPN 2 DD-WRT routers, route internet thru VPN? Reply with quote
I have a pair of DD-WRT routers installed at two different locations with a working site-to-site VPN configured in the scripts under the "Commands" tab. This working VPN allows me to access local resources of each location from the other location. Internet is currently NOT redirected through the VPN, with each site using its own public WAN IP for internet traffic.

My question is how do I get one computer connected to the VPN client router as 192.168.4.202 to direct its internet traffic through the VPN. I am trying to set up routing for a specific IP address for this purpose, and show the new code I added to the scripts in red below. The code in black is the existing working VPN code. What happens with this code is that the client at 192.168.4.202 cannot connect to the internet at all (nonresponive browser), and all other clients not using .202 still connect to the internet fine.

VPN Server Router at Site A uses subnet 192.168.0.x, NetGear R7000 DD-WRT v3.0-r36070M kongac (05/31/18 )
Code:

Startup Script
------------------
# Move to writable directory and create scripts
cd /tmp
ln -s /usr/sbin/openvpn /tmp/myvpn

# Config for Site-to-Site SiteA-SiteB
# ping-timer-rem needed on server to keep openvpn from restarting itself with long delays.
# auth-nocache removes a warning about caching passwords in memory on server.
# cipher AES-256-CBC override default cipher that is vulnerable to SWEET32 hack.
echo "
proto udp4
port 2000
dev tun0
secret /tmp/static.key
cipher AES-256-CBC
verb 4
comp-lzo
keepalive 15 60
ping-timer-rem
auth-nocache
daemon
" > SiteA-SiteB.conf

# Config for Static Key
echo "
-----BEGIN OpenVPN Static key V1-----
[MyStaticKeyHexCodes]
-----END OpenVPN Static key V1-----
" > static.key

# Create interface
/tmp/myvpn --mktun --dev tun0
ifconfig tun0 10.0.0.1 netmask 255.255.255.0 promisc up

# Create route
route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.0.0.2

# Initiate the tunnel
sleep 5
/tmp/myvpn --config SiteA-SiteB.conf

Firewall Script
-------------------
# Open firewall holes for VPN
iptables -I INPUT 2 -p udp --dport 2000 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

# Allow ping over VPN
iptables -I INPUT 3 -i tun0 -p icmp -j ACCEPT

# Allow router admin over VPN
iptables -I INPUT 1 -i tun0 -p tcp --dport 80 -j ACCEPT

iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE


VPN Client Router at Site B uses subnet 192.168.4.x, NetGear R7000 DD-WRT v3.0-r36070M kongac (05/31/18 )

(The client connected as 192.168.4.202 should send its internet traffic through the VPN.)

Code:

Startup Script
------------------
# Move to writable directory and create scripts
cd /tmp
ln -s /usr/sbin/openvpn /tmp/myvpn
# Config for Site-to-Site SiteA-SiteB
# auth-nocache removes a warning about caching passwords in memory on client.
# cipher AES-256-CBC override default cipher that is vulnerable to SWEET32 hack.
echo "
remote [My DYNDNS Service]
proto udp4
port 2000
dev tun0
secret /tmp/static.key
cipher AES-256-CBC
verb 3
comp-lzo
keepalive 15 60
auth-nocache
daemon
" > SiteA-SiteB.conf

# Config for Static Key
echo "
-----BEGIN OpenVPN Static key V1-----
[MyStaticKeyHexCodes]
-----END OpenVPN Static key V1-----
" > static.key

# Create interface
/tmp/myvpn --mktun --dev tun0
ifconfig tun0 10.0.0.2 netmask 255.255.255.0 promisc up

# Create route
route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.1


# Initiate the tunnel
sleep 5
/tmp/myvpn --config SiteA-SiteB.conf


#Use VPN tun0 for internet access from 192.168.4.202
ip route add default via 10.0.0.1 dev tun0 table 200
ip rule add from 192.168.4.202 table 200
ip route flush cache

Code:

Firewall Script
-------------------
# Open firewall holes for VPN
iptables -I INPUT 2 -p udp --dport 2000 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT


I ran these diagnostics on the server router
Code:

iptables -vnL INPUT

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1570  158K ACCEPT     tcp  --  tun0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
 1644  292K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    1    96 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:2000
    0     0 ACCEPT     icmp --  tun0   *       0.0.0.0/0            0.0.0.0/0           
    2   659 ACCEPT     udp  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
    0     0 DROP       udp  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 DROP       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
   80  9724 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           
    2   395 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       icmp --  vlan2  *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       2    --  *      *       0.0.0.0/0            0.0.0.0/0           
    2   120 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0           
  128  8305 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0   

iptables -vnL FORWARD

No output

iptables -t nat -vnL POSTROUTING

Chain POSTROUTING (policy ACCEPT 13 packets, 4027 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   31  2016 SNAT       0    --  *      vlan2   192.168.0.0/24       0.0.0.0/0           to:[My public IP address for Site A]
    2   172 SNAT       0    --  *      vlan2   192.168.2.0/24       0.0.0.0/0           to:[My public IP address for Site A]
    0     0 MASQUERADE  0    --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x80000000/0x80000000
   42  2734 MASQUERADE  0    --  *      vlan2   0.0.0.0/0            0.0.0.0/0

ip route show table main

default via [First Three Numbers of My public IP address for Site A].1 dev vlan2
10.0.0.0/24 dev tun0 scope link  src 10.0.0.1
[First Three Numbers of My public IP address for Site A].0/19 dev vlan2 scope link  src [My public IP address for Site A]
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev br0 scope link  src 169.254.255.1
192.168.0.0/24 dev br0 scope link  src 192.168.0.1
192.168.2.0/24 dev br1 scope link  src 192.168.2.1
192.168.4.0/24 via 10.0.0.2 dev tun0

ip rule list

0:   from all lookup local
32766:   from all lookup main
32767:   from all lookup default


I ran these diagnostics on the client router
Code:

iptables -vnL INPUT

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1284  233K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:2000
    0     0 ACCEPT     udp  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
    0     0 DROP       udp  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 DROP       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 DROP       icmp --  vlan2  *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       2    --  *      *       0.0.0.0/0            0.0.0.0/0           
    3   180 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
  225 15077 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
   10   400 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           

iptables -vnL FORWARD

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  576  154K ACCEPT     0    --  tun0   br0     0.0.0.0/0            0.0.0.0/0           
  686 75261 ACCEPT     0    --  br0    tun0    0.0.0.0/0            0.0.0.0/0           
  101 13312 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     47   --  *      vlan2   192.168.4.0/24       0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      vlan2   192.168.4.0/24       0.0.0.0/0           tcp dpt:1723
    2   136 lan2wan    0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     0    --  br0    br0     0.0.0.0/0            0.0.0.0/0           
    0     0 TRIGGER    0    --  vlan2  br0     0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0
    2   136 trigger_out  0    --  br0    *       0.0.0.0/0            0.0.0.0/0           
    2   136 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           

iptables -t nat -vnL POSTROUTING

Chain POSTROUTING (policy ACCEPT 198 packets, 14003 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    2   136 SNAT       0    --  *      vlan2   192.168.4.0/24       0.0.0.0/0           to:[My public IP address for Site B]
    0     0 MASQUERADE  0    --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x80000000/0x80000000

ip route show table main

default via [First Three Numbers of My public IP address for Site B].1 dev vlan2
10.0.0.0/24 dev tun0 scope link  src 10.0.0.2
[First Three Numbers of My public IP address for Site B].0/21 dev vlan2 scope link  src [My public IP address for Site B]
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev br0 scope link  src 169.254.255.1
192.168.0.0/24 via 10.0.0.1 dev tun0
192.168.4.0/24 dev br0 scope link  src 192.168.4.1

ip route show table 200

default via 10.0.0.1 dev tun0

ip rule list

0:   from all lookup local
32765:   from 192.168.4.202 lookup 200
32766:   from all lookup main
32767:   from all lookup default
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12917
Location: Netherlands

PostPosted: Thu Aug 16, 2018 16:37    Post subject: Reply with quote
A question, as you have the client setup manually, there could be a missing nat rule on the client side something like:
Code:
iptables -I POSTROUTING -t nat -o tun0 -j MASQUERADE


Just guessing Smile

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
tkoyn
DD-WRT User


Joined: 11 Feb 2007
Posts: 442

PostPosted: Fri Aug 17, 2018 2:37    Post subject: Reply with quote
eibgrad wrote:
You got the following on the server side?!

Code:
iptables -vnL FORWARD

No output


How can that be? Whatever is causing this needs to be corrected because it's NOT normal.
I reran the command on the server router and obtained the below. There seems to be a bug in the GUI command shell window where sometimes it comes back blank.
Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     0    --  tun0   br0     0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     0    --  br0    tun0    0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     47   --  *      vlan2   192.168.0.0/24       0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      vlan2   192.168.0.0/24       0.0.0.0/0           tcp dpt:1723
 7721 3944K ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0           
19576 6855K lan2wan    0    --  *      *       0.0.0.0/0            0.0.0.0/0           
18957 6816K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  br0    br0     0.0.0.0/0            0.0.0.0/0           
  619 38809 ACCEPT     0    --  br0    vlan2   0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     0    --  br1    vlan2   0.0.0.0/0            0.0.0.0/0           
    0     0 TRIGGER    0    --  vlan2  br0     0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0
    0     0 trigger_out  0    --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0

egc wrote:
A question, as you have the client setup manually, there could be a missing nat rule on the client side something like:
Code:
iptables -I POSTROUTING -t nat -o tun0 -j MASQUERADE


Just guessing Smile
I added this to the firewall script of the client and it does not help, internet still dead from 192.68.4.202 instead of going through VPN. Adding this rule did affect the result of iptables -t nat -vnL POSTROUTING on the client router, as it now produces
Code:
Chain POSTROUTING (policy ACCEPT 243 packets, 19068 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   37  2368 MASQUERADE  0    --  *      tun0    0.0.0.0/0            0.0.0.0/0           
  111  7921 SNAT       0    --  *      vlan2   192.168.4.0/24       0.0.0.0/0           to:[My public IP address for Site B]
    0     0 MASQUERADE  0    --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x80000000/0x80000000
What should I try next to get this working?
tkoyn
DD-WRT User


Joined: 11 Feb 2007
Posts: 442

PostPosted: Fri Aug 17, 2018 3:49    Post subject: Reply with quote
eibgrad wrote:
cat /proc/net/ip_conntrack | grep 192.168.4.202[/code]
Should I run this on the client router, or on the server router, or both?

And before I run the above command, should I remove the below rule egc suggested I add to the client to return to the original scripts in my first post?

Client nat rule:
iptables -I POSTROUTING -t nat -o tun0 -j MASQUERADE

Also, on the server side, should I change the below rule (to what) or remove it?

Server nat rule:
iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE
tkoyn
DD-WRT User


Joined: 11 Feb 2007
Posts: 442

PostPosted: Fri Aug 17, 2018 5:32    Post subject: Reply with quote
eibgrad wrote:
Just noticed. I don't see any FORWARD rule on the server side to allow incoming packets to pass from the OpenVPN tunnel (tun0) to the WAN (vlan2).

Code:
iptables -I FORWARD -i tun0 -o vlan2 -j ACCEPT
Adding this to the server seems to have fixed the issue.

Do you recommend keeping the two below rules, or, are they extra?

Client nat rule suggested by egc:
iptables -I POSTROUTING -t nat -o tun0 -j MASQUERADE

Server nat rule I had since the first post of this thread:
iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE
tkoyn
DD-WRT User


Joined: 11 Feb 2007
Posts: 442

PostPosted: Fri Aug 17, 2018 14:48    Post subject: Reply with quote
eibgrad wrote:
There's no need to NAT the OpenVPN tunnel on the client side. Each side is already capable of routing to the other side because each has the necessary routing information in their respective routing tables. NAT just adds unnecessary overhead and masks the actual source IP of the client should you want to filter based on it.
OK, eliminating this line from client firewall works:
iptables -I POSTROUTING -t nat -o tun0 -j MASQUERADE

eibgrad wrote:
On the server side, I suggest you be consistent when it comes to NAT'ing over the WAN (vlan2). By default, 192.168.0.0/24 is already NAT'd by the router. And when you added the 192.168.2.0/24 network on that same side, you added an SNAT rule. So do the same for the 192.168.4.0/24 network as well (rather than NAT'ing everything unconditionally).

Code:
iptables -t nat -I POSTROUTING -s 192.168.4.0/24 -o vlan2 -j SNAT --to ...
The routing of the internet through the VPN breaks if I replace these on the server

iptables -I FORWARD -i tun0 -o vlan2 -j ACCEPT
iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE

with this

iptables -t nat -I POSTROUTING -s 192.168.4.0/24 -o vlan2 -j SNAT --to `nvram get wan_ipaddr`
Per Yngve Berg
DD-WRT Guru


Joined: 13 Aug 2013
Posts: 6870
Location: Romerike, Norway

PostPosted: Fri Aug 17, 2018 19:26    Post subject: Reply with quote
Continue to use MASQUERADE instead of SNAT.

iptables -t nat -A POSTROUTING -s 192.168.4.0/24 -o `get_wanface` -j MASQUERADE
tkoyn
DD-WRT User


Joined: 11 Feb 2007
Posts: 442

PostPosted: Fri Aug 17, 2018 21:41    Post subject: Reply with quote
eibgrad wrote:
I wasn't suggesting you eliminate the following.

Code:
iptables -I FORWARD -i tun0 -o vlan2 -j ACCEPT


That's still a requirement. I'm merely suggesting you replace the following ...

Code:
# this is unconditional!
iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE


with ...

Code:
# this is conditional; it only applies to 192.168.4.0/24
iptables -t nat -I POSTROUTING -s 192.168.4.0/24 -o vlan2 -j SNAT --to `nvram get wan_ipaddr`


because it's more consistent with what you did when you needed 192.168.2.0/24 to have the same access over the WAN.
OK, this does work. About the SNAT rule for 192.168.2.x, that was generated when I added a guest WiFi network using the GUI under WiFi settings and also the networking settings to put that virtual WiFi on its own subnet with a bridge (which is working and was not intended to be part of this discussion).

Per Yngve Berg wrote:
Continue to use MASQUERADE instead of SNAT.

iptables -t nat -A POSTROUTING -s 192.168.4.0/24 -o `get_wanface` -j MASQUERADE
What is the difference between these two options and why is MASQUERADE better? If I switch, it would be for the use VPN for internet situation as I did not code the rule for the guest WiFi network on 192.168.2.x.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking 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 cannot attach files in this forum
You cannot download files in this forum