Packets not forwarding through VPN

jtbr

Hello,

I've set up an openvpn server on ubuntu on a virtual machine in the cloud, using the script found at https://github.com/Angristan/OpenVPN-install. I want clients to forward all traffic via the VPN server using NAT on the server. Among other things, this script sets /proc/sys/ipv4/ip_forward to 1, and runs

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to PUB.LIC.IPA.DDR

where the IP address is the public IP of the server.

As it stands, clients can connect just fine, but the packets never cross the VPN tunnel gateway at 10.8.0.1 (I've tried connecting with openvpn clients for windows 7 and ios 8.3 and same results). I can't figure out why packets are not being forwarded. The following is from a windows client:

$ tracert -d 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

  1   160 ms   160 ms   160 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

traceroute from the server to 8.8.8.8 succeeds, and I can wget from websites using the server. There are no special iptables rules that I know of:

$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 22575 packets, 3302K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 267 packets, 14850 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 43230 packets, 4619K bytes)
 pkts bytes target     prot opt in     out     source               destination

I'm sure there's something I'm missing, and I'd really appreciate any tips you might have. The server and client configurations follow. Many thanks!

server.conf

port 2194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
persist-key
persist-tun
crl-verify crl.pem

client.ovpn

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote XX.XX.XX.XX 2194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
XXXXX
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
XXXXX
-----BEGIN CERTIFICATE-----
XXXXX
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
XXXXXX
-----END PRIVATE KEY-----
</key>

Traffic

jtbr wroteI'd really appreciate any tips you might have

Set --verb 4 in your configs and then check your logs for errors ..

Also, post iptables -t nat -L and sysctl net.ipv4.ip_forward of the server.

jtbr

Thanks for your help. I'm not seeing any potential errors on the client side, even with verb 4.

On the server side, it also looks fine to except for the last line:

Apr 10 18:03:39 servername ovpn-server[5616]: OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan  4 2016
Apr 10 18:03:39 servername ovpn-server[5616]: library versions: OpenSSL 1.0.1f 6 Jan 2014, LZO 2.06
Apr 10 18:03:39 servername ovpn-server[5617]: Diffie-Hellman initialized with 2048 bit key
Apr 10 18:03:39 servername ovpn-server[5617]: Control Channel Authentication: using 'tls-auth.key' as a OpenVPN static key file
Apr 10 18:03:39 servername ovpn-server[5617]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 10 18:03:39 servername ovpn-server[5617]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 10 18:03:39 servername ovpn-server[5617]: TLS-Auth MTU parms [ L:1601 D:1140 EF:110 EB:0 ET:0 EL:3 ]
Apr 10 18:03:39 servername ovpn-server[5617]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 10 18:03:39 servername ovpn-server[5617]: TUN/TAP device tun0 opened
Apr 10 18:03:39 servername ovpn-server[5617]: TUN/TAP TX queue length set to 100
Apr 10 18:03:39 servername ovpn-server[5617]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Apr 10 18:03:39 servername ovpn-server[5617]: /sbin/ip link set dev tun0 up mtu 1500
Apr 10 18:03:39 servername ovpn-server[5617]: /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
Apr 10 18:03:39 servername ovpn-server[5617]: Data Channel MTU parms [ L:1601 D:1450 EF:101 EB:12 ET:0 EL:3 ]
Apr 10 18:03:39 servername ovpn-server[5617]: GID set to nogroup
Apr 10 18:03:39 servername ovpn-server[5617]: UID set to nobody
Apr 10 18:03:39 servername ovpn-server[5617]: UDPv4 link local (bound): [undef]
Apr 10 18:03:39 servername ovpn-server[5617]: UDPv4 link remote: [undef]
Apr 10 18:03:39 servername ovpn-server[5617]: MULTI: multi_init called, r=256 v=256
Apr 10 18:03:39 servername ovpn-server[5617]: IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Apr 10 18:03:39 servername ovpn-server[5617]: ifconfig_pool_read(), in='other-client,10.8.0.2', TODO: IPv6
Apr 10 18:03:39 servername ovpn-server[5617]: succeeded -> ifconfig_pool_set()
Apr 10 18:03:39 servername ovpn-server[5617]: IFCONFIG POOL LIST
Apr 10 18:03:39 servername ovpn-server[5617]: other-client,10.8.0.2
Apr 10 18:03:39 servername ovpn-server[5617]: Initialization Sequence Completed
Apr 10 18:06:35 servername ovpn-server[5617]: MULTI: multi_create_instance called
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Re-using SSL/TLS context
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Control Channel MTU parms [ L:1601 D:1140 EF:110 EB:0 ET:0 EL:3 ]
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Data Channel MTU parms [ L:1601 D:1450 EF:101 EB:12 ET:0 EL:3 ]
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Local Options String: 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Local Options hash (VER=V4): '08e9aab2'
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Expected Remote Options hash (VER=V4): '0e1bd53a'
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 TLS: Initial packet from [AF_INET]CLIENTIP:56365, sid=8d27ca4c 2400e68d
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 CRL CHECK OK: CN=ChangeMe
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 VERIFY OK: depth=1, CN=ChangeMe
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 CRL CHECK OK: CN=other-client
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 VERIFY OK: depth=0, CN=other-client
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 2048 bit RSA
Apr 10 18:06:35 servername ovpn-server[5617]: CLIENTIP:56365 [other-client] Peer Connection Initiated with [AF_INET]CLIENTIP:56365
Apr 10 18:06:35 servername ovpn-server[5617]: other-client/CLIENTIP:56365 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Apr 10 18:06:35 servername ovpn-server[5617]: other-client/CLIENTIP:56365 MULTI: Learn: 10.8.0.2 -> other-client/CLIENTIP:56365
Apr 10 18:06:35 servername ovpn-server[5617]: other-client/CLIENTIP:56365 MULTI: primary virtual IP for other-client/CLIENTIP:56365: 10.8.0.2
Apr 10 18:06:37 servername ovpn-server[5617]: other-client/CLIENTIP:56365 PUSH: Received control message: 'PUSH_REQUEST'
Apr 10 18:06:37 servername ovpn-server[5617]: other-client/CLIENTIP:56365 send_push_reply(): safe_cap=940
Apr 10 18:06:37 servername ovpn-server[5617]: other-client/CLIENTIP:56365 SENT CONTROL [other-client]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 50.116.23.211,dhcp-option DNS 104.238.153.178,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0' (status=1)
Apr 10 18:06:38 servername ovpn-server[5617]: other-client/CLIENTIP:56365 MULTI: bad source address from client [::], packet dropped

(after renaming the servername and CLIENTIP)

sysctl net.ipv4.ip_forward shows:

net.ipv4.ip_forward = 1

Maybe the 'iptables -t nat -L' is showing the issue -- it looks like the machine may be interpreting the IP address range as internal to the amazon aws ec2 cloud (?) and somehow that's breaking things:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  ip-10-8-0-0.us-west-1.compute.internal/24  anywhere             to:PUB.LIC.IPA.DDR

(where PUB.LIC.IPA.DDR is the public IP address of the server)

Perhaps I could use a different IP address range?

jtbr

To follow up, I tried using the IP address range 192.168.240.0/24 instead of 10.8.0.0/24 but there was no change; still won't forward packets.

The 'iptables -t nat -L' command now shows:

SNAT     all   --   ip-192-168-240-0.us-west-1.compute.internal/24   anywhere           to:PUB.LIC.IPA.DDR

It looks like it's recognizing it's a local network but I'm not sure whether that's affecting anything.

Traffic

jtbr wroteThe 'iptables -t nat -L' command now shows:

SNAT     all   --   ip-192-168-240-0.us-west-1.compute.internal/24   anywhere           to:PUB.LIC.IPA.DDR

Delete that and use this:

iptables -t nat -A POSTROUTING -s {vpn subnet e.g: 10.8.0.0/24} -j SNAT --to-source {Server public ip e.g: 12.34.56.78}

the reason for SNAT not MASQUERADE is because your cloud server probably does not support MASQ ..

Please see the HOWTO:
HOWTO: Routing all client traffic (including web-traffic) through the VPN

jtbr

Thanks again. That got me on the right track.

That's the same command I was using (except I used '--to', not '--to-source', although I don't think that matters). BUT, when I tried this after clearing out the other rules (iptables -t nat -F):

iptables -t nat -A POSTROUTING -s {vpn subnet e.g: 10.8.0.0/24} -o eth0 -j MASQUERADE

now, it seems to be forwarding correctly! I thought I'd tried this earlier, but other things might have been wrong then. Is it possible the cloud provider doesn't support SNAT then perhaps?

In any case, many thanks.

Traffic

jtbr wrotenow, it seems to be forwarding correctly!

With MASQUERADE .. ok

jtbr wroteIs it possible the cloud provider doesn't support SNAT then perhaps?

Perhaps .. I expect they will tell you if you ask them :ugeek: