# VPN Tunnel [solved]

## alienjon

Hi all,

I have DD-WRT installed on my home router and it's a flavor with OpenVPN installed on it.  I'm trying to get the server setup in such a way so that I can connect to it and tunnel to the Internet.  I'm testing with an Android phone with OpenVPN Client installed.  Right now I can get a VPN IP address, but I can't seem to figure out how to connect to the Internet.

Hy home network is 192.168.1.* and my VPN is 192.168.5.*.

I've made sure to enable redirect gateway on both the server and client side (not sure if both are needed) and I've also setup a route on the client side to 192.168.1.0/24 with a route-gateway option set to 192.168.1.1.

Log on both the client and server show the VPN connection being setup, but no errors are noted and nothing jumps out at me as being overtly wrong:

```
292 TLS: new session incoming connection from [AF_INET]70.192.8.61:3292

Jun 18 03:39:19 DD-WRT daemon.notice openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 VERIFY OK: depth=1, C=US, ST=MA, L=Fiskdale, O=Devolved, OU=owner, CN=homeVPN, name=alienjon, emailAddress=alienjon@devolved.noip.me

Jun 18 03:39:19 DD-WRT daemon.notice openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 VERIFY OK: depth=0, C=US, ST=MA, L=Fiskdale, O=Devolved, OU=owner, CN=AndyTheAndroid, name=alienjon, emailAddress=alienjon@devolved.noip.me

Jun 18 03:39:19 DD-WRT daemon.warn openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 WARNING: 'tun-ipv6' is present in remote config but missing in local config, remote='tun-ipv6'

Jun 18 03:39:19 DD-WRT daemon.notice openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key

Jun 18 03:39:19 DD-WRT daemon.notice openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication

Jun 18 03:39:19 DD-WRT daemon.notice openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key

Jun 18 03:39:19 DD-WRT daemon.notice openvpn[1631]: AndyTheAndroid/70.192.8.61:3292 NOTE: --mute triggered...

```

I also have the following in the server firewall commands:

```
/usr/sbin/iptables -I INPUT -p udp --dport 1194 -j ACCEPT

/usr/sbin/iptables -I FORWARD -i br0 -o tun2 -j ACCEPT

/usr/sbin/iptables -I FORWARD -i tun2 -o br0 -j ACCEPT

/usr/sbin/iptables -I FORWARD 1 --source 192.168.1.0/24 -j ACCEPT
```

Last edited by alienjon on Mon Jun 20, 2016 2:01 am; edited 1 time in total

----------

## Hu

Do you mean that the phone is using some other form of connection instead of the VPN (such as the carrier's data plan) or that the phone tries to use the VPN, but cannot connect to the Internet through the VPN?  Are there any computers wired into the LAN that are able to access the Internet?  If yes, that proves the DD-WRT is configured to provide Internet service at least in some cases.  Are you using the VPN to tunnel the phone from an Internet hotspot back to the DD-WRT for privacy (in which case the connection comes from the Internet) or is the phone associated to an in-home wireless router and using the VPN as an alternative to WPA2 (in which case the connection comes from the LAN side)?  Your /var/log/messages seems to support the idea that you are connecting from the Internet.

It would be helpful to get the output of ip route ; ip addr (or equivalent) from both devices, when the VPN is up.  If you do not otherwise use the DD-WRT for routing, check that you have enabled IP forwarding in /proc/sys/net/ipv4/ip_forward.  The iptables rules you show reference a bridge device.  Bridging is not necessary for this purpose, but can be used.  The required configuration differs depending on whether you want to bridge or to route.  Please also provide the output of brctl show ; iptables-save from the DD-WRT and iptables-save from the Android.  You may need to find equivalent alternate commands for one or both devices.  These commands are the ones you would use with a fully installed GNU/Linux distribution like standard Gentoo.

----------

## alienjon

 *Hu wrote:*   

> Do you mean that the phone is using some other form of connection instead of the VPN (such as the carrier's data plan) or that the phone tries to use the VPN, but cannot connect to the Internet through the VPN? Are there any computers wired into the LAN that are able to access the Internet?

 

The phone is using the mobile data connection to connect to the VPN (so it goes over the cellular network to connect to my home VPN), but cannot connect to the Internet once connected to the VPN.  My home network is able to connect to the Internet just fine (so I'm positive it's an OpenVPN configuration issue somewhere).  On the DDWRT router, `ip addr` returns nothing, but `ip route` results in:

```
default via {home IP} dev vlan2

{home IP}/22 dev vlan2  proto kernel  scope link  src {home IP}

127.0.0.0/8 dev lo  scope link

169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1

192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1

192.168.2.0/24 dev wl0.1  proto kernel  scope link  src 192.168.2.1

192.168.3.0/24 dev wl1.1  proto kernel  scope link  src 192.168.3.1

192.168.5.0/24 dev tun2  proto kernel  scope link  src 192.168.5.1
```

Also:

```

bridge name     bridge id               STP enabled     interfaces

br0             8000.04a151e94144       no              vlan1

                                                        eth1

                                                        eth2
```

However, iptables-save does not exist on the router.  I'll try to update later when I have time to run these on my phone and figure out how to get ip addr and iptables-save on the router.

Lastly, though, I did update my iptables commands:

```
/usr/sbin/iptables -I INPUT -p udp --dport 1194 -j ACCEPT

/usr/sbin/iptables -I FORWARD -i br0 -o tun2 -j ACCEPT

/usr/sbin/iptables -I FORWARD -i tun2 -o br0 -j ACCEPT

/usr/sbin/iptables -I FORWARD 1 --source 192.168.1.0/24 -j ACCEPT

/usr/sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
```

The last entry seemed to be what fixed the problem for some others, though I may have the device wrong (I haven't had a whole lot of time to test, but eth0 doesn't do the trick).  I appreciate all the tips, I hope I've addressed all of them, but will follow-up with the other things later tonight.

----------

## Hu

No output from ip addr is weird, but I can guess what you need from the other output.  Assuming that your problem is related to routing, then the POSTROUTING rule should name the interface you use for Internet uplink.  Based on the ip route output, that would be vlan2, since it is your default route.

----------

## alienjon

 *Hu wrote:*   

> No output from ip addr is weird

 It is, but I'm not entirely surprised.  I think bash output is redirected somehow (`ip -V` also returns blank).  Also, man pages aren't available on the device (likely to save space - it is a router with limited resources).  I can't find another command to do the equivalent.  Would this usually give the local IP of the router?  It would come up as 192.168.1.1 (I can access it via SSH and http at this address).

 *Hu wrote:*   

>  the POSTROUTING rule should name the interface you use for Internet uplink. Based on the ip route output, that would be vlan2, since it is your default route.

 Good point.  Changing to vlan2 didn't change it, though.

On another note from your first post:

 *Hu wrote:*   

> check that you have enabled IP forwarding in /proc/sys/net/ipv4/ip_forward

 There isn't an 'IP forwarding' option in the DD WRT configuration page, though:

```
1
```

so it looks enabled to me.  As for the bridging device, I think it's how the router handles a few things.  It's a dual band wireless router and DD WRT allows for virtual wireless interfaces (plus the Ethernet ports).  I'm far from a networking guru, but I think the bridge simply connects all these interfaces (w0, w1, et al).  As for iptables-save, it seems that the command was removed from dd-wrt to save space a few years ago.  I ran the following instead (and posting it via pastebin, due to it's length): iptables -nL.  Unfortunately, it doesn't look like I can get iptables on my phone (Android) without it being rooted (which I can't do, unfortunately).  Is there something similar that may not need route I could use to get the same/similar info?

Because I can connect to the VPN I suspect the problem is either with the firewall or some setting on the client/server side.  Below is the info on both:

DD-WRT OpenVPN server config:

```
dh /tmp/openvpn/dh.pem

ca /tmp/openvpn/ca.crt

cert /tmp/openvpn/cert.pem

key /tmp/openvpn/key.pem

keepalive 10 120

verb 3

mute 3

syslog

writepid /var/run/openvpnd.pid

management 127.0.0.1 14

management-log-cache 100

topology subnet

script-security 2

port 1194

proto udp

cipher aes-128-cbc

auth sha256

client-connect /tmp/openvpn/clcon.sh

client-disconnect /tmp/openvpn/cldiscon.sh

client-config-dir /jffs/etc/openvpn/ccd

comp-lzo adaptive

tls-server

ifconfig-pool-persist /tmp/openvpn/ip-pool 86400

client-to-client

push "redirect-gateway def1"

fast-io

tun-mtu 1500

mtu-disc yes

server 192.168.5.0 255.255.255.0

dev tun2

tun-ipv6

```

This isn't a config file, as it's a GUI configuration on my phone's side, but the info as it's currently setup:

Remote Servers

Remote Server: {WAN IP}:1194 UDP

Authentication

Authentication mode: Certificates (TLS)

'Use TLS HMAC authentication': disabled {default}

Cryptography

Cipher algorithm: AES-128-CBC {default}

Authentication Algorithm: SHA256 {default}

Negotiate key every (sec.): [enabled {default}] and set to 3600 {default}

Renegotiate key every (bytes): disabled {default}

Renegotiate key every (pkts): disabled {default}

Options

Use old stable OpenVPN 2.3.2: disabled {default}

Use tap device: disabled {default} <- also requires root

Pull configuration: enabled {default}

Set IPv4 address: disabled {default}

Enable IPv6: disabled {default}

Ignore pushed DNS servers: disabled {default}

Set DNS servers: disabled {default}

Set DNS suffix: disabled {default}

Set LZO compression: enabled {default}, set to 'adaptive' {default}

Set keepalive: disabled {default}

Set ping: disabled {default}

Set ping restart: disabled {default}

Set ping exit: disabled {default}

Limit outgoing bandwidth (bytes/sec.): disabled {default}

Pause when screen is off: disabled {default}

Drop packets on connect/reconnect/unexpected disconnect: disabled {default}

Don't keep track of the VPN usage: disabled {default}

Routing

IPv4 Routing:

Redirect gateway: enabled {default}

Not route the local network: disabled {default}

IPv4 Routes: 192.168.1.0/24

IPv6 Routing:

Redirect gateway: enabled {default}

IPv6 routes: {none added}

Custom Options

remote-cert-tls server

route-gateway 192.168.1.1

verb 4

----------

## alienjon

Quick update (possibly solved).  I think the MASQUERADE iptables command was wrong.  The -s was set to the gateway, but this seemed odd to me (as how would it then know to connect it to the VPN subnet).  I checked the man page and -s is the source, which I think WOULD be the VPN subnet.  Keeping the rest as is (though -o is now set to vlan2) and updating the subnet to 192.168.5.0 SEEMS to let me connect to the Internet.  I'll test some more, but does that makes sense otherwise?

----------

## Hu

Running ip addr would have showed the address for each interface, not just the internal one.

Your solution makes sense.  Changing the interface name was necessary but insufficient.  The source was not set to the gateway, since it had a /24 on it.  It was set to the subnet used by your LAN.  In simple setups with no bridging, such a rule is required to masquerade the internal machines to the public IP of the router.  Similarly, you need that rule here, otherwise the router will likely pass the VPN traffic to the outside world with the source address still referring to 192.168.5.x.  Upstream devices would, at best, discard the request as nonsensical.  More commonly, they would just keep forwarding it on until it reached a machine that needed to respond, but that machine would not be able to get its response to you, because both it and all the intervening machines would need a route stating that you use 192.168.5.x.  Since that is a private range address, machines outside your organization should not have such a route.

----------

## alienjon

That seems to have fixed it.  I was able to connect from a different region and see both my other LAN devices as well as the Internet at large.  Thanks for the help!

----------

