OpenVPN Clients Connects to Server, but no access to web

[nasface]

Hi Everyone,

I've been trying to set up my NAS box to connect to a VPN server I have set-up with another company.

I had a load of issues getting the tun module set-up with the NAS box kernel, but that seems to be fixed now and OpenVPN is connecting successfully.

The problem is, that when OpenVPN is connected, I can no longer access the web, if I curl google.co.uk I get the following output:

Code: Select all

curl www.google.co.uk
curl: (7) couldn't connect to host

The output from OpenVPN as it connects is:

Code: Select all

Sat Feb 23 11:23:33 2013 OpenVPN 2.2.2 armv5tel-unknown-linux-gnueabi [SSL] [LZO2] [EPOLL] [eurephia] built on Nov  4 2012
Sat Feb 23 11:23:33 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Feb 23 11:23:33 2013 Control Channel Authentication: tls-auth using INLINE static key file
Sat Feb 23 11:23:33 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Feb 23 11:23:33 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Feb 23 11:23:33 2013 LZO compression initialized
Sat Feb 23 11:23:33 2013 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Feb 23 11:23:33 2013 Socket Buffers: R=[112640->131072] S=[112640->131072]
Sat Feb 23 11:23:33 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Feb 23 11:23:33 2013 Local Options hash (VER=V4): '504e774e'
Sat Feb 23 11:23:33 2013 Expected Remote Options hash (VER=V4): '14168603'
Sat Feb 23 11:23:33 2013 UDPv4 link local: [undef]
Sat Feb 23 11:23:33 2013 UDPv4 link remote: 46.246.117.4:8292
Sat Feb 23 11:23:33 2013 TLS: Initial packet from 46.246.117.4:8292, sid=db052e52 27c17ad0
Sat Feb 23 11:23:33 2013 Replay-window backtrack occurred [1]
Sat Feb 23 11:23:34 2013 VERIFY OK: depth=1, /C=../ST=../L=../O=../OU=../CN=ASCA/emailAddress=..
Sat Feb 23 11:23:34 2013 VERIFY OK: nsCertType=SERVER
Sat Feb 23 11:23:34 2013 VERIFY OK: depth=0, /C=../ST=../L=../O=../OU=../CN=server-46.246.117.4/emailAddress=..
Sat Feb 23 11:23:34 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Feb 23 11:23:34 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Feb 23 11:23:34 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Feb 23 11:23:34 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Feb 23 11:23:34 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Feb 23 11:23:34 2013 [server-46.246.117.4] Peer Connection Initiated with 46.246.117.4:8292
Sat Feb 23 11:23:36 2013 SENT CONTROL [server-46.246.117.4]: 'PUSH_REQUEST' (status=1)
Sat Feb 23 11:23:36 2013 PUSH: Received control message: 'PUSH_REPLY,sndbuf 262144,rcvbuf 262144,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 5.5.0.1,ping 10,ping-restart 90,comp-lzo no,route-gateway 5.5.0.1,topology subnet,ifconfig 5.5.5.173 255.255.240.0'
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: timers and/or timeouts modified
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: LZO parms modified
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sat Feb 23 11:23:36 2013 Socket Buffers: R=[131072->262142] S=[131072->262142]
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: --ifconfig/up options modified
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: route options modified
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: route-related options modified
Sat Feb 23 11:23:36 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Feb 23 11:23:36 2013 ROUTE default_gateway=192.168.1.254
Sat Feb 23 11:23:36 2013 TUN/TAP device tun0 opened
Sat Feb 23 11:23:36 2013 TUN/TAP TX queue length set to 100
Sat Feb 23 11:23:36 2013 /ffp/sbin/ifconfig tun0 5.5.5.173 netmask 255.255.240.0 mtu 1500 broadcast 5.5.15.255
Sat Feb 23 11:23:36 2013 /ffp/sbin/route add -net 46.246.117.4 netmask 255.255.255.255 gw 192.168.1.254
Sat Feb 23 11:23:36 2013 /ffp/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 5.5.0.1
Sat Feb 23 11:23:36 2013 /ffp/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 5.5.0.1
Sat Feb 23 11:23:36 2013 Initialization Sequence Completed

the netstat -rn output is when connected:

Code: Select all

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
46.246.117.4    192.168.1.254   255.255.255.255 UGH       0 0          0 egiga0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 egiga0
5.5.0.0         0.0.0.0         255.255.240.0   U         0 0          0 tun0
0.0.0.0         5.5.0.1         128.0.0.0       UG        0 0          0 tun0
128.0.0.0       5.5.0.1         128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 egiga0

Code: Select all

ifconfig
egiga0    Link encap:Ethernet  HWaddr FC:F5:28:30:89:EA  
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1593 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1804 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:271779 (265.4 KiB)  TX bytes:414396 (404.6 KiB)
          Interrupt:11 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1071 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:317100 (309.6 KiB)  TX bytes:317100 (309.6 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:5.5.5.173  P-t-P:5.5.5.173  Mask:255.255.240.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

My gut instinct is that traffic isn't getting routed properly but where that is failing I'm not sure. Does anyone have any ideas? If there are any more bits of info / tasks I can complete to find out what is wrong please let me know and I'll gladly run them.

[SmoothwallUser]

Can you please provide an output of both the client.ovpn and server.conf files? (server.conf might have other files, like server.red.conf, server.blue.conf, server.orange.conf, server.purple.conf [Smoothwall])

There are possibilities of failure:
1. The NAT is not enabled for the tun0 device on your OpenVPN Server to go out to the WAN.
2. The routing to 0.0.0.0/0 is not present
3. The DNS Settings are not there on your client
4. Firewall denying access possibly

Here are outputs from my Smoothie OpenVPN Settings and my client settings:

Code: Select all

/var/smoothwall/ovpn/server.red.conf
#OpenVPN red server conf

config /var/smoothwall/ovpn/server.conf
writepid /var/run/openvpn.rw.red.pid
proto tcp
port 1194
dev tun0
server 10.239.32.0 255.255.255.0
push "route 10.0.0.0 255.255.255.248"
push "route 0.0.0.0 0.0.0.0" --> might need possibly. Testing this input on my Smoothie Firewall.
push "route-gateway dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
push "dhcp-option DOMAIN home.local"

Code: Select all

Ben-TO-SW.ovpn (Windows 7 Client)
#OpenVPN Server conf
tls-client
client
dev tun
proto tcp
tun-mtu 1500
auth-nocache
route-metric 512
route 0.0.0.0 0.0.0.0
#http-proxy 10.0.0.1 800
remote 192.168.1.100 1194
#http-proxy-retry
#remote 172.16.0.1 1195
pkcs12 Ben.p12
cipher BF-CBC
verb 3
ns-cert-type server

Code: Select all

NAT settings that need to be added /etc/rc.d/rc.firewall.up (My Smoothie Firewall)
# OpenVPN NAT
/sbin/iptables -t nat -A POSTROUTING -s 10.239.32.0/24 -o eth2 -j MASQUERADE
/sbin/iptables -t nat -A POSTROUTING -s 10.239.33.0/24 -o eth2 -j MASQUERADE
/sbin/iptables -t nat -A POSTROUTING -s 0.0.0.0/0 -o eth2 -j MASQUERADE --> might need this possibly
/sbin/iptables -I FORWARD -i eth2 -o tun0 -j ACCEPT
/sbin/iptables -I FORWARD -i tun0 -o eth2 -j ACCEPT
/sbin/iptables -I FORWARD -i eth2 -o tun1 -j ACCEPT
/sbin/iptables -I FORWARD -i tun1 -o eth2 -j ACCEPT

[nasface]

The config file is:

Code: Select all

setenv FORWARD_COMPATIBLE 1
setenv UV_SERVERID X
client
dev tun
proto udp
remote XXX.XXX.XXX.X XXXX
nobind
persist-key
persist-tun
ns-cert-type server
key-direction 1
push-peer-info
comp-lzo
explicit-exit-notify
verb 3
mute 20
reneg-sec 86400
mute-replay-warnings
max-routes 1000
<ca>
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
XXX
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
XXX
-----END OpenVPN Static key V1-----
</tls-auth>

I don't have the server conf because I'm not in control of this.

I'm fairly sure it's not my router since I can connect to the VPN from my desktop and all traffic works correctly. I've compared the logs between my desktop and the NAS box and there are barely any differences. The route tables look the same, just in a different order. I though the route with the higher metric might be the cause, but have altering the table it didn't change anything.

I've not installed any firewall's on the box, but that doesn't mean there isn't one already installed with the box.

Is there any way to identify if there is a firewall preventing the connections going through?

[SmoothwallUser]

Your configuration file is right, except to access the web, the protocol (proto) should be tcp not udp since udp is the intranet (internal network) and tcp uses the Internet, and most likely the internal network.

Whoever is the network administrator for the OpenVPN Server, have him switch the OpenVPN protocol from UDP to TCP in either the server.conf file, or by web access from a computer. Also, UDP doesn't allow pinging or access to the Internet. I had that problem, but it went away after changing settings here and there, and both my laptop and smartphone (Feat VPN is installed on my smartphone) have Internet access to both my router and firewall via OpenVPN.

[nasface]

I had actually tried a different server with TCP instead of UDP.

TCP didn't make any difference, I imagine curl would still work while ping'ing wouldn't.

Also raises the question why UDP would work on my desktop but not my NAS box??

[SmoothwallUser]

I think it's because the NAS uses TCP for various reasons, especially accessing the NAS from another computer. Does your desktop connect to the Internet when connected to the OpenVPN server?

[nasface]

Connecting, with the conf file, on my desktop works and I can connect to the internet.

SSH'ing into the NAS box starting OpenVPN works but I can't then run the curl command to access the internet. On the NAS box I've tried UDP and TCP configs, box with the same result, they'll connect but won't allow access to the internet.

[SmoothwallUser]

That's strange. Can you ping from your desktop to your NAS machine? If so, then pinging between machines are successful, and it would most likely be no DNS settings on the NAS. Can you post an output of your resolv.conf from your NAS box? And just out of curiosity, is the DNS address the same as the default gateway (5.5.0.1)? If there is no DNS record in the NAS box, you will or might have to add the following to the resolv.conf file:

Code: Select all

nameserver XXX.XXX.XXX.X

where X is the OpenVPN server's default gateway.
Note: when it says nameserver 127.0.0.1 in the resolv.conf, that's the machie's DNS settings for the loopback device.

[nasface]

Still trying

The resolv.conf is:
nameserver 192.168.1.254

I tried adding in the IP address of the VPN server but had no luck.

1. I just realised the /ffp/etc/resolv.conf is a broken link, it points to /ffp/etc/original/resolv.conf which doesn't exist. This to me suggests one of two things, either this is designed for a case where software alters resolv.conf and backs-up somewhere or it should never be like this.

2. The resolv.conf config never changes. I've set the IP to the VPN server but still don't seem to get anywhere

3. I just realised the dnsmasq package, wondering if that might help propagate changes....

I haven't tried pinging the box yet, but I can SSH in.

[nasface]

Just an FYI: I can ping from my desktop to the NAS box and the other way around.

[SmoothwallUser]

Still trying

The resolv.conf is:
nameserver 192.168.1.254

I tried adding in the IP address of the VPN server but had no luck.

1. I just realised the /ffp/etc/resolv.conf is a broken link, it points to /ffp/etc/original/resolv.conf which doesn't exist. This to me suggests one of two things, either this is designed for a case where software alters resolv.conf and backs-up somewhere or it should never be like this.

2. The resolv.conf config never changes. I've set the IP to the VPN server but still don't seem to get anywhere

3. I just realised the dnsmasq package, wondering if that might help propagate changes....

I haven't tried pinging the box yet, but I can SSH in.

Try rebooting the NAS machine, and, if needed, add these lines to the resolv.conf file and reboot (required for the DNS settings to kick in):

Code: Select all

nameserver 208.67.222.222
nameserver 208.67.220.220

Try out the dnsmasq package and post an output.
Also, that's good news that you can ping fron your NAS to your desktop and vice versa.
In addition to the resolv.conf, the nameserver 192.168.1.254 points out to your router, I persume, since I noticed in the netstat -rn output you put on here earlier has your gateway. Without the OpenVPN connected, it connects to the Internet, right?

[SmoothwallUser]

Also, if needed, type in:

Code: Select all

route default gw 192.168.1.254 egiga0
route default gw 5.5.0.1 tun0

and use either curl or ping to test connectivity (ex. curl www.google.com, ping -c 4 www.google.com), and post any output after issuing the commands. Also, for the routes to be used automatically, make a new file called routes in /etc/rc.d

Code: Select all

vi routes

then, push either the I (insert) or A (append) key(s); copy and paste the route commands I have implemented at the top of this post as follows:

Code: Select all

# Routes to OpenVPN
/sbin/route default gw 192.168.1.254 egiga0
/sbin/route default gw 5.5.0.1 tun0

push the esc (escape) key, type in :w, hit enter, and :wq, hit enter.
Then, type in the following command to make the file as an executable script file:

Code: Select all

chmod +x routes

Open up the sysinit (rc.sysinit) file with vi, go all the way to the bottom (way before the Silencing kernel), push a, or I, and type in the following:

Code: Select all

# Automatic Route Start
./routes

push esc, type in :w, enter, and :wq, enter.

[nasface]

The only problem with these commands is:

a.) I'm assuming you want me to use add with the route command
b.) the tun0 device isn't created until openvpn is started, which creates the interface. I'm assuming running these commands afterwards is no issue?

After running the route commands, curl still fails, as does ping.

I just found out the following from a NAS forum where I posted the same problem:

NASFace wrote:
1. I just realised the /ffp/etc/resolv.conf is a broken link, it points to /ffp/etc/original/resolv.conf which doesn't exist. This to me suggests one of two things, either this is designed for a case where
software alters resolv.conf and backs-up somewhere or it should never be like this.


It has 'grown' that way. FFP used to be chrooted, and /etc was bindmounted on /ffp/etc/original/, while the /etc within the chroot was a symlink to /ffp/etc.

So /etc/resolv.conf within the chroot pointed to /etc/resolv.conf outside the chroot, and it should, as the ip config is handled by the firmware.

Now FFP isn't chrooted anymore, so /etc/resolv.conf is just available, and /ffp/etc/resolv.conf isn't used. (It never was. DNS is handled by firmware)

Within the admin page for the NAS box, I have the option to set a static ip as well as DNS servers on the box, which seem to then get applied to resolv.conf from boot. But my attempts to set appropriate values have always failed so far.

It seems like the values from this section of the openvpn log:

Code: Select all

Tue Feb 26 20:28:14 2013 ROUTE default_gateway=192.168.1.254
Tue Feb 26 20:28:14 2013 TUN/TAP device tun0 opened
Tue Feb 26 20:28:14 2013 TUN/TAP TX queue length set to 100
Tue Feb 26 20:28:14 2013 /ffp/sbin/ifconfig tun0 5.5.5.173 netmask 255.255.240.0 mtu 1500 broadcast 5.5.15.255
Tue Feb 26 20:28:14 2013 /ffp/sbin/route add -net 46.246.117.4 netmask 255.255.255.255 gw 192.168.1.254
Tue Feb 26 20:28:14 2013 /ffp/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 5.5.0.1
Tue Feb 26 20:28:14 2013 /ffp/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 5.5.0.1

Need to link up to:



I tried setting the default gateway to 5.5.0.1 and it seemed that curl could find the IP address but not connect to it and the same happened with setting it to the IP of the VPN server.

Code: Select all

curl www.google.co.uk
curl: (7) Failed to connect to 173.194.67.94: Unknown error 101

[SmoothwallUser]

Try to issue these commands in you ZyXel NAS box:

Code: Select all

iptables -t nat -A POSTROUTING -s 5.5.0.0/20 -o egiga0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 0.0.0.0/0 -o egiga0 -j MASQUERADE --> might need this possibly
iptables -I FORWARD -i eth2 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o eth2 -j ACCEPT

These commands might work, or they won't. Also, I've observed the /ffp/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 5.5.0.1 and the /ffp/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 5.5.0.1 commands that your post has, the route command should be /ffp/sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 5.5.0.1 not separate since when usig either curl or ping, it'll go to the first route that is listed, and google's P address is 174.*.*.* which can cause failure. I might be wrong.

[nasface]

iptables is one command I don't have on the box and don't seem to be able to get either.

I have ip, ipaddr, ipcrm, ipcs, iplink, iproute, iprule. I also found an update_ip.sh script, but it doesn't seem to work unforunately, errors out or without vpn running.

[SmoothwallUser]

Is there a way to install iptables, and what version of ZyXel are you using?