| View previous topic :: View next topic |
| Author |
Message |
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
 Posted: Sat Jun 18, 2016 3:45 am Post subject: VPN Tunnel [solved] |
 |
|
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:
| only the last few lines of /var/log/messages: | 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:
| Code: | /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 |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Sat Jun 18, 2016 3:35 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sat Jun 18, 2016 6:34 pm Post subject: |
|
|
| 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:
| ip route: | 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:
| brctl show: |
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:
| Code: | /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. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Sat Jun 18, 2016 8:20 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sun Jun 19, 2016 2:24 am Post subject: |
|
|
| 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:
| cat /proc/sys/net/ipv4/ip_forward: | | 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:
| cat /tmp/openvpn/openvpn.conf: | 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 |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sun Jun 19, 2016 2:33 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Sun Jun 19, 2016 7:29 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Mon Jun 20, 2016 2:01 am Post subject: |
|
|
| 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! |
|
| Back to top |
|
|
|
|
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
|
|
Networking & Security
