OpenVPN: Initialization Sequence Completed

xdino · 05-18-2016, 01:56 PM

So for the past 4 days I've tried everything to fix OpenVPN but still it's not working. I try and browse the web but the spinner just keeps spinning and ping does not receive packets.

Here's what the terminal gives me after running sudo openvpn --config Ubuntu.ovpn

Code:

Wed May 18 13:41:29 2016 OpenVPN 2.3.2 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014
Wed May 18 13:41:29 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Wed May 18 13:41:29 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Wed May 18 13:41:29 2016 UDPv4 link local: [undef]
Wed May 18 13:41:29 2016 UDPv4 link remote: [AF_INET]52.38.217.247:1194
Wed May 18 13:41:29 2016 TLS: Initial packet from [AF_INET]52.38.217.247:1194, sid=c333ba3d 85c45e62
Wed May 18 13:41:30 2016 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=odin, OU=odin, CN=odin CA, name=server, emailAddress=cats@gmail.com
Wed May 18 13:41:30 2016 VERIFY OK: nsCertType=SERVER
Wed May 18 13:41:30 2016 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=odin, OU=odin, CN=server, name=server, emailAddress=cats@gmail.com
Wed May 18 13:41:31 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed May 18 13:41:31 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 18 13:41:31 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed May 18 13:41:31 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 18 13:41:31 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Wed May 18 13:41:31 2016 [server] Peer Connection Initiated with [AF_INET]52.38.217.247:1194
Wed May 18 13:41:33 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed May 18 13:41:34 2016 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,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.10 10.8.0.9'
Wed May 18 13:41:34 2016 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 18 13:41:34 2016 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 18 13:41:34 2016 OPTIONS IMPORT: route options modified
Wed May 18 13:41:34 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed May 18 13:41:34 2016 ROUTE_GATEWAY 10.0.0.1/255.255.255.0 IFACE=eth0 HWADDR=10:78:d2:9a:9c:96
Wed May 18 13:41:34 2016 TUN/TAP device tun0 opened
Wed May 18 13:41:34 2016 TUN/TAP TX queue length set to 100
Wed May 18 13:41:34 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 18 13:41:34 2016 /sbin/ip link set dev tun0 up mtu 1500
Wed May 18 13:41:34 2016 /sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
Wed May 18 13:41:34 2016 /sbin/ip route add 52.38.217.247/32 via 10.0.0.1
Wed May 18 13:41:34 2016 /sbin/ip route add 0.0.0.0/1 via 10.8.0.9
Wed May 18 13:41:34 2016 /sbin/ip route add 128.0.0.0/1 via 10.8.0.9
Wed May 18 13:41:34 2016 /sbin/ip route add 10.8.0.1/32 via 10.8.0.9
Wed May 18 13:41:34 2016 GID set to nogroup
Wed May 18 13:41:34 2016 UID set to nobody
Wed May 18 13:41:34 2016 Initialization Sequence Completed

Here's my client Ubuntu.ovpn file

Code:

client
dev tun
proto udp
remote 52.38.217.247 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
dhcp-option DNS 8.8.8.8

And here's the server.conf file

Code:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key 
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

sundialsvcs · 05-18-2016, 04:14 PM

We need more details, actually ...

"Let's start with ping" You neglected to tell us which IP-address you are trying to ping!

Gee, I don't see any route commands in that configuration ... none in the client file, and none being pushed from the server. The routing that we see in the log-file seems to more-or-less confirm this:

Code:

Wed May 18 13:41:34 2016 /sbin/ip route add 52.38.217.247/32 via 10.0.0.1

... okay, this is how you get to the VPN host (52.38.217.247) by what appears to be
... your gateway (10.0.0.1)

Wed May 18 13:41:34 2016 /sbin/ip route add 0.0.0.0/1 via 10.8.0.9
Wed May 18 13:41:34 2016 /sbin/ip route add 128.0.0.0/1 via 10.8.0.9

... dunno what to make of a "/1" netmask!

Wed May 18 13:41:34 2016 /sbin/ip route add 10.8.0.1/32 via 10.8.0.9

... it appears that ONLY "10.8.0.1" gets routed through the tunnel!

Remember that an OpenVPN (tunnel-mode ...) connection acts as a virtual router, and therefore, "all the ground-rules of 'being a router'" apply. The router occupies a single address ... the so-called "gateway address" ... on your local network. Then, there must be "routing commands" which specify the range of IP-addresses that are supposed to be "routed through" that gateway.

(Basically, "who cares that it isn't a physical box?" It is still 'a router.'")

Try this command: ip route get 1.2.3.4 (substituting some address of interest to you ...). This will tell you exactly how a packet to any given address will be "routed" by your machine.

You should find that there is a tunN interface ... that's the virtual VPN tunnel ... and that "traffic which you wish to be encrypted by the tunnel" must be passing through it.

Right now, I suspect that nothing is being routed through the tunnel, which BTW is probably being successfully(!) established.

xdino · 05-18-2016, 04:32 PM

@sundialsvcs Ok so how do I set up a route to pass my connection through the tunnel? Here's what the ip command gives me:

Code:

dino@dino:~/ip route get 93.184.216.34
93.184.216.34 via 10.8.0.9 dev tun0  src 10.8.0.10 
    cache

and ping example

Code:

PING 93.184.216.34 (93.184.216.34) 56(84) bytes of data.
^C
--- 93.184.216.34 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 52416ms

and here's my routing table after I start openvpn if that helps:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.9        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.8.0.1        10.8.0.9        255.255.255.255 UGH   0      0        0 tun0
10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
52.38.217.247   10.0.0.1        255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.0.9        128.0.0.0       UG    0      0        0 tun0

sundialsvcs · 05-18-2016, 08:26 PM

The only way that I could address this question would be to say: [i]"investigate whether-or-not all(!) of the following directives make sense:

Code:

/sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
/sbin/ip route add 52.38.217.247/32 via 10.0.0.1
/sbin/ip route add 0.0.0.0/1 via 10.8.0.9
/sbin/ip route add 128.0.0.0/1 via 10.8.0.9
/sbin/ip route add 10.8.0.1/32 via 10.8.0.9

... because, these are the directives that were issued to your host, when you (apparently, successfully ...) connected this tunnel.

xdino · 05-19-2016, 02:28 PM

Quote:

Originally Posted by sundialsvcs

The only way that I could address this question would be to say: [i]"investigate whether-or-not all(!) of the following directives make sense:

Code:

/sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
/sbin/ip route add 52.38.217.247/32 via 10.0.0.1
/sbin/ip route add 0.0.0.0/1 via 10.8.0.9
/sbin/ip route add 128.0.0.0/1 via 10.8.0.9
/sbin/ip route add 10.8.0.1/32 via 10.8.0.9

... because, these are the directives that were issued to your host, when you (apparently, successfully ...) connected this tunnel.

Still couldn't fix it since I know nothing about using linux routes. But I figured out how to use ssh tunneling using socks proxy. So far it works.

xdino · 05-20-2016, 05:25 PM

Quote:

Originally Posted by sundialsvcs

The only way that I could address this question would be to say: [i]"investigate whether-or-not all(!) of the following directives make sense:

Code:

/sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
/sbin/ip route add 52.38.217.247/32 via 10.0.0.1
/sbin/ip route add 0.0.0.0/1 via 10.8.0.9
/sbin/ip route add 128.0.0.0/1 via 10.8.0.9
/sbin/ip route add 10.8.0.1/32 via 10.8.0.9

... because, these are the directives that were issued to your host, when you (apparently, successfully ...) connected this tunnel.

Ok I fixed it by running this line on the server:

Code:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

and iptables -f on the client