[Solved] No internet connection

zpeti

After installing openvpn on Ubuntu and CentOS and running into the same problem, I'm a bit desperate for help. I've been through every other thread with the same problem and the solutions aren't working.

I've installed OpenVPN on a CentOS server and I'm using TunnelBlick on a Mac. The server and client connect fine, and can ping each other, but I cannot access or ping anything from the client machine (including any DNS servers it's not a dns problem).

Here's my server.conf:

local x.x.x.x (my public IP)
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
verb 3

And client:

client
dev tun
proto udp
remote x.x.x.x (public ip again) 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3

The usual problem of forwarding ips is fine, sysctl -p reads:

sysctl -p
net.ipv4.ip_forward = 1

And iptables -L reads:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:openvpn
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

While iptables -S reads:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

I've run the usual "iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE" and nothing improves.

I am trying to connect from my Mac via a router, I'm not sure if this could be a problem and how to avoid it?

I've looked through about 50 threads today on this and haven't found a solution, can anyone help?

Thanks!

zpeti

Just to show nat table as well, iptables -t nat -L reads:

Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 10.8.0.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

zpeti

So by server "subnet" does that mean the whole of the internet which should be included? Or are the 3 different subnets, the local client LAN, the server LAN, and the internet?

zpeti

Is it possible to get a bit more help? I'm really struggling here.

I tried adding a route push to the server config with the public IP address being pushed, that hasn't worked.

(tbh the server has no LAN, it is a standalone server that should get internet traffic routed via it). I've also tried adding this to iptables as it's one extra option that I've found in blog posts but it hasn't worked:

Chain POSTROUTING (policy ACCEPT)
SNAT all -- 10.8.0.0/16 anywhere to:212.227.91.145

This is the final line of the server logs when I connect:

Thu Nov 14 12:01:07 2013 client/31.55.35.30:54194 SENT CONTROL [client]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

And some final lines from tunnelblick when it connects.

CUR_SMB_WG = ; CUR_SMB_WA =
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: ServerAddresses were not aggregated because running on OS X 10.6 or higher
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: FIN_DNS_DN = openvpn; FIN_DNS_SA = 8.8.8.8 8.8.4.4; FIN_DNS_SD = openvpn
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: FIN_SMB_NN = ; FIN_SMB_WG = ; FIN_SMB_WA =
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: OS X 10.7 and neither ServerAddresses nor SearchDomains were set manually, so will modify DNS settings using only State:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_DNS = ; SKP_DNS_SA = ; SKP_DNS_SD = ; SKP_DNS_DN =
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_SETUP_DNS = #
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_SMB = #; SKP_SMB_NN = #; SKP_SMB_WG = #; SKP_SMB_WA = #
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: /etc/resolve = nameserver 192.168.22.22 nameserver 192.168.22.23
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: scutil --dns BEFORE CHANGES = DNS configuration resolver #1 nameserver[0] : 192.168.22.22 nameserver[1] : 192.168.22.23 resolver #2 domain : local options : mdns timeout : 5 order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 order : 301000 DNS configuration (for scoped queries) resolver #1 nameserver[0] : 192.168.22.22 nameserver[1] : 192.168.22.23 if_index : 4 (en0) flags : Scoped
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Configuration changes:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: ServerAddresses 8.8.8.8 8.8.4.4
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: SearchDomains openvpn
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: DomainName openvpn
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: #ADD Setup: ServerAddresses 8.8.8.8 8.8.4.4
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: #ADD Setup: SearchDomains openvpn
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: #ADD Setup: DomainName openvpn
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: NetBIOSName
2013-11-14 12:06:15 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: Workgroup
2013-11-14 12:06:16 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: WINSAddresses
2013-11-14 12:06:16 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:16 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Pause for configuration changes to be propagated to State:/Network/Global/DNS and .../SMB
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Configurations as read back after changes:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/.../DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 8.8.8.8 8.8.4.4 } }
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/.../SMB = No such key
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Setup:/.../DNS = No such key
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Setup:/.../SMB = No such key
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/Global/DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 8.8.8.8 8.8.4.4 } }
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/Global/SMB = No such key
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Expected by process-network-changes:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/OpenVPN/DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 8.8.8.8 8.8.4.4 } }
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/OpenVPN/SMB = <dictionary> { TunnelblickNoSuchKey : true }
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: /etc/resolve = search openvpn nameserver 8.8.8.8 nameserver 8.8.4.4
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG: scutil --dns AFTER CHANGES = DNS configuration resolver #1 search domain[0] : openvpn nameserver[0] : 8.8.8.8 nameserver[1] : 8.8.4.4 resolver #2 domain : local options : mdns timeout : 5 order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 order : 301000 DNS configuration (for scoped queries) resolver #1 search domain[0] : openvpn nameserver[0] : 8.8.8.8 nameserver[1] : 8.8.4.4 if_index : 4 (en0) flags : Scoped
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: DEBUG:
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: Saved the DNS and SMB configurations for later use
2013-11-14 12:06:17 *Tunnelblick: No 'connected.sh' script to execute
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: Flushed the DNS Cache
2013-11-14 12:06:17 *Tunnelblick client.up.tunnelblick.sh: Set up to monitor system configuration with leasewatch

I really can't seem to find any other information out there, any guide or description says everything should work by now. What am I doing wrong?

zpeti

Looking at this useful picture, I'm arriving at the "firewall issue" box at the bottom...

Can't ping 8.8.8.8
Forwarding is enabled
NAT iptables rule added
client and server aren't on the same lan, it's a hosted server

Is it possible my hosting company is somehow blocking VPN traffic?

zpeti

I turned off iptables and I still got the same result.

However, when I run "tcpdump -i eth0 udp port 1194" and connect the client I can see traffic going through.

10:21:23.686553 IP xxxxxxx.onlinehome-server.info.openvpn > host86-161-181-64.range86-161.btcentralplus.com.63295: UDP, length 125
10:21:23.716999 IP host86-161-181-64.range86-161.btcentralplus.com.63295 > xxxxxxx.onlinehome-server.info.openvpn: UDP, length 101
10:21:24.387770 IP host86-161-181-64.range86-161.btcentralplus.com.63295 > xxxxxxx.onlinehome-server.info.openvpn: UDP, length 109
10:21:24.389411 IP host86-161-181-64.range86-161.btcentralplus.com.63295 > xxxxxxx.onlinehome-server.info.openvpn: UDP, length 109
10:21:24.699748 IP host86-161-181-64.range86-161.btcentralplus.com.63295 > xxxxxxx.onlinehome-server.info.openvpn: UDP, length 101
10:21:24.699826 IP xxxxxxx.onlinehome-server.info.openvpn > host86-161-181-64.range86-161.btcentralplus.com.63295: UDP, length 125
10:21:24.719531 IP host86-161-181-64.range86-161.btcentralplus.com.63295 > xxxxxxx.onlinehome-server.info.openvpn: UDP, length 101

Since that is going through eth0, does that mean internet traffic is being downloaded to the server it just isn't being forwarded back to me? How can that be if I've enabled forwarding and masquerading?

zpeti

No, I didn't. Is that something you manually have to do if you are behind a router at home connecting to a remote vpn server?

How do paid VPN service companies get around this problem? Their client software just connects from wherever I use them?

zpeti

Yes it does. I'm trying to route my traffic through it.

zpeti

This is my output for "netstat -nr" on the client when the VPN is running.

I see the gateway as 10.8.0.5 several times, that is the client machine's IP though, is that right?

PetiLaptop:~ pete$ netstat -nr
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
0/1 10.8.0.5 UGSc 8 0 tun0
default 10.100.103.1 UGSc 33 0 en0
10.8.0.1/32 10.8.0.5 UGSc 1 0 tun0
10.8.0.5 10.8.0.6 UH 13 0 tun0
10.100.103/24 link#4 UCS 9 0 en0
10.100.103.1 44:3:a7:67:f:90 UHLWIi 2 14 en0 1090
10.100.103.45 c0:63:94:49:36:cc UHLWIi 0 0 en0 1118
10.100.103.77 40:a6:d9:5d:8:e8 UHLWIi 0 0 en0
10.100.103.125 54:ea:a8:d1:d2:57 UHLWIi 0 0 en0 1089
10.100.103.139 40:a6:d9:84:52:87 UHLWIi 0 0 en0
10.100.103.142 a0:ed:cd:5d:22:6a UHLWIi 0 0 en0 249
10.100.103.145 127.0.0.1 UHS 0 4 lo0
10.100.103.146 cc:78:5f:ab:ef:be UHLWIi 0 0 en0 1108
10.100.103.147 90:b2:1f:b7:23:cb UHLWIi 0 0 en0 139
10.100.103.255 ff:ff:ff:ff:ff:ff UHLWbI 0 12 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 4 2936 lo0
128.0/1 10.8.0.5 UGSc 2 0 tun0
169.254 link#4 UCS 1 0 en0
169.254.255.255 44:3:a7:67:f:90 UHLSW 0 0 en0
212.227.91.145/32 10.100.103.1 UGSc 1 0 en0

zpeti

OK it looks like it was a firewall issue, I managed to get it working with some help.

This doesn't seem mentioned in most setup guides, so I thought I'd share it here. There's quite a few iptables rules that need to be changed from a fresh installation. (for example, many guides don't have iptables rules for allowing UDP traffic at all):

iptables -A INPUT -p udp --dport 1194 -j ACCEPT

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -s XXX.XXX.XXX.XXX -o eth0 -j MASQUERADE

I hope this helps someone else with the same problem.