Server and Client use wrong IP configuration

[curahack]

Hi,

First off, I've been having this problem on 2 different servers trying to get a fully functional OpenVPN server. I've been google-ing for a long time and still haven't gotten a clue what's driving this problem. As my final hope I tought I should post my problem here.

This is my server configuration:

Code: Select all

    dev tun
    proto udp
    port 1194

    ca /etc/openvpn/keys/ca.crt
    cert /etc/openvpn/keys/server.crt
    key /etc/openvpn/keys/server.key
    dh /etc/openvpn/keys/dh1024.pem

    user nobody
    group nogroup
    server 10.8.0.0 255.255.255.0

    persist-key
    persist-tun

    #status openvpn-status.log
    #verb 3
    client-to-client

    push "redirect-gateway def1"

    #log-append /var/log/openvpn
    comp-lzo 

And this is the client config:

Code: Select all

    dev tun
    client
    proto udp
    remote ***.***.***.*** 1194
    resolv-retry infinite
    nobind
    user nobody
    group nogroup

    # Try to preserve some state across restarts.
    persist-key
    persist-tun
    ca ca.crt
    cert client1.crt
    key client1.key
    comp-lzo

    # Set log file verbosity.
    verb 3 

The client successfully connects to the Server, but the IP configuration given to the client by the server doesn't make any sense. To my knowledge, with this configuration the virtual network shouldn't be a point-to-point network but a subnet-based network. Allowing the server to communicate to multiple clients at the same time. Before I go on let me show you the IP configuration of both the server as the client:

Server:

Code: Select all

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

Client:

Code: Select all

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:2384 (2.3 KB)

This doesn't make any sense to me, why is this happening? I even tried the example config written on this website, but I got the same result...

Any clue?

[maikcat]

hi there,

the configs are ok
the ip your clients get is also ok...


taken from docs

--topology mode
Configure virtual addressing topology when running in --dev tun mode. This directive has no meaning in --dev tap mode, which always uses a subnet topology.

If you set this directive on the server, the --server and --server-bridge directives will automatically push your chosen topology setting to clients as well. This directive can also be manually pushed to clients. Like the --dev directive, this directive must always be compatible between client and server.

mode can be one of:

net30 -- Use a point-to-point topology, by allocating one /30 subnet per client. This is designed to allow point-to-point semantics when some or all of the connecting clients might be Windows systems. This is the default on OpenVPN 2.0.

p2p -- Use a point-to-point topology where the remote endpoint of the client's tun interface always points to the local endpoint of the server's tun interface. This mode allocates a single IP address per connecting client. Only use when none of the connecting clients are Windows systems. This mode is functionally equivalent to the --ifconfig-pool-linear directive which is available in OpenVPN 2.0 and is now deprecated.

subnet -- Use a subnet rather than a point-to-point topology by configuring the tun interface with a local IP address and subnet mask, similar to the topology used in --dev tap and ethernet bridging mode. This mode allocates a single IP address per connecting client and works on Windows as well. Only available when server and clients are OpenVPN 2.1 or higher, or OpenVPN 2.0.x which has been manually patched with the --topology directive code. When used on Windows, requires version 8.2 or higher of the TAP-Win32 driver. When used on *nix, requires that the tun driver supports an ifconfig(8) command which sets a subnet instead of a remote endpoint IP address.

This option exists in OpenVPN 2.1 or higher.


Michael.

[curahack]

OK, I've added "topology subnet" to both the config of the client and the server. I am able to recieve internet through the VPN (see traceroute) but after a while the connection drops due to the following error:

Code: Select all

Sun Jul  3 11:16:30 2011 Initialization Sequence Completed
Sun Jul  3 11:19:29 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jul  3 11:19:29 2011 TLS Error: TLS handshake failed
Sun Jul  3 11:19:29 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jul  3 11:19:29 2011 TLS Error: TLS handshake failed

I also noticed that I can't ping (timeouts) the client from the server side but when I ping the server from the client I get the following result:

Code: Select all

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
From 10.8.0.1 icmp_seq=1 Destination Port Unreachable
From 10.8.0.1 icmp_seq=2 Destination Port Unreachable

Here's the server's ifconfig:

Code: Select all

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:10299 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14026 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:4906159 (4.9 MB)  TX bytes:15947762 (15.9 MB)

And the client:

Code: Select all

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.4  P-t-P:10.8.0.4  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:223 errors:0 dropped:0 overruns:0 frame:0
          TX packets:280 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:94028 (94.0 KB)  TX bytes:209902 (209.9 KB)

Here's the traceroute to Google (which is working fine):

Code: Select all

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  46.133 ms  47.554 ms  49.051 ms
 2  vserver40012.mifl01.hostnoc.net (184.22.112.98)  50.469 ms  51.898 ms  52.805 ms
 3  ec0-63.gwy02.mifl01.hostnoc.net (64.120.243.133)  55.357 ms  56.202 ms  57.726 ms
 4  xe0-10.gwy01.sctn01.hostnoc.net (64.120.243.121)  96.447 ms  97.785 ms  98.823 ms
 5  96.9.191.34 (96.9.191.34)  247.713 ms  247.882 ms  247.891 ms
 6  core1-0-2-0.lga.net.google.com (198.32.160.130)  107.399 ms  90.489 ms  86.652 ms
 7  72.14.238.232 (72.14.238.232)  87.366 ms 209.85.255.68 (209.85.255.68)  88.147 ms  89.617 ms
 8  72.14.239.93 (72.14.239.93)  91.271 ms 209.85.249.11 (209.85.249.11)  92.743 ms ^C

So 2 things: why am I unable to ping within the VPN and does this cause the TLS handshake failure (if not how can I fix it)?

Thank you!

[maikcat]

hi there,

>TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

this error mostly means that something between your server-client
breaks connection.
it might be your internet router
it might be some type of firewall that discards packets

suggestion for testing,switch to tcp...

Michael.

[curahack]

No unfortunately TCP isn't working, it seems to be looping this:

Code: Select all

Tue Jul  5 08:02:11 2011 Attempting to establish TCP connection with [AF_INET]184.22.124.50:1194 [nonblock]
Tue Jul  5 08:02:12 2011 TCP connection established with [AF_INET]184.22.124.50:1194
Tue Jul  5 08:02:12 2011 TCPv4_CLIENT link local: [undef]
Tue Jul  5 08:02:12 2011 TCPv4_CLIENT link remote: [AF_INET]184.22.124.50:1194
Tue Jul  5 08:02:12 2011 Connection reset, restarting [0]
Tue Jul  5 08:02:12 2011 SIGUSR1[soft,connection-reset] received, process restarting
Tue Jul  5 08:02:17 2011 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul  5 08:02:17 2011 Re-using SSL/TLS context
Tue Jul  5 08:02:17 2011 LZO compression initialized
Tue Jul  5 08:02:17 2011 Attempting to establish TCP connection with [AF_INET]184.22.124.50:1194 [nonblock]
Tue Jul  5 08:02:18 2011 TCP connection established with [AF_INET]184.22.124.50:1194
Tue Jul  5 08:02:18 2011 TCPv4_CLIENT link local: [undef]
Tue Jul  5 08:02:18 2011 TCPv4_CLIENT link remote: [AF_INET]184.22.124.50:1194
Tue Jul  5 08:02:18 2011 Connection reset, restarting [0]
Tue Jul  5 08:02:18 2011 SIGUSR1[soft,connection-reset] received, process restarting
Tue Jul  5 08:02:23 2011 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul  5 08:02:23 2011 Re-using SSL/TLS context
Tue Jul  5 08:02:23 2011 LZO compression initialized
Tue Jul  5 08:02:23 2011 Attempting to establish TCP connection with [AF_INET]184.22.124.50:1194 [nonblock]
Tue Jul  5 08:02:24 2011 TCP connection established with [AF_INET]184.22.124.50:1194

[maikcat]

can you post server logs aswell?

Michael.

[curahack]

Here you go...

Code: Select all

Tue Jul  5 08:58:03 2011 ***client***,10.8.0.4
Tue Jul  5 08:58:03 2011 Initialization Sequence Completed
Tue Jul  5 08:58:05 2011 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]190.112.231.11:55106
Tue Jul  5 08:58:07 2011 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]190.112.231.11:55106
Tue Jul  5 08:58:09 2011 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]190.112.231.11:55106
Tue Jul  5 08:58:12 2011 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]190.112.231.11:55106
Tue Jul  5 08:58:14 2011 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]190.112.231.11:55106

[maikcat]

hi there,

can you increase verb to 5 and post logs from server/client again?

Michael.

ps:stupid question,the ca.crt is the same for server/client right?

[curahack]

Hi there, sorry for the delay, I was away for a while, but I'm back.

I've re-configured the whole VPN and strarted over let me show you the configs:
Server:

Code: Select all

#####################################################
#  OpenVPN Server Configuration
#####################################################
#local <LOCALIP>
port 1194
proto udp
dev tun

# Openvpn 2.1 and above: script-security 3 system
ca /etc/openvpn/CuraShare/ca.crt
cert /etc/openvpn/CuraShare/CuraShare.crt
key /etc/openvpn/CuraShare/CuraShare.key

dh /etc/openvpn/CuraShare/dh-CuraShare.pem

topology subnet
server 10.8.0.0 255.255.255.0   

;client-to-client

up "/etc/openvpn/**********"
down "/etc/openvpn/*********"
down-pre

ifconfig-pool-persist /etc/openvpn/CuraShare/ipp.txt
;ifconfig-pool-linear

#  Ping every 10 seconds, assume remote is down afte 120 seconds
keepalive 10 120

tls-server
tls-auth /etc/openvpn/CuraShare/ta.key 0

cipher AES-128-CBC
;comp-lzo
max-clients 300

user root
group root

persist-key
persist-tun

status-version 2
status /etc/openvpn/logs/openvpn-CuraShare-status.log
log /etc/openvpn/logs/openvpn-CuraShare.log
crl-verify /etc/openvpn/CuraShare/crl.pem

verb 3
mute 20

push "redirect-gateway def1"

Client: (Nothing special)

Code: Select all

client
dev tun
route-delay 10

# Openvpn 2.1 and above: script-security 3 system

#cd /etc/openvpn
#up "/etc/openvpn/up.sh"
#down-pre
#down "/etc/openvpn/down.sh"

proto udp
remote ***** 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings

ca CuraShare-****/ca.crt
cert CuraShare-****/CuraShare-****.crt
key CuraShare-****/CuraShare-****.key

ns-cert-type server

tls-client
tls-auth CuraShare-***/ta.key 1

cipher AES-128-CBC
;comp-lzo

verb 3
mute 20

I've censored some things, so don't mind the ***

When the client connects I get a full connection, I can ping the server (10.8.0.1) and I can use the server as gateway (browse the internet over the VPN) because I configured the server to do so with iptables.
But after a while the clients echo's a message saying it's renewing it's LTS-encryption:

Code: Select all

Tue Aug  9 11:06:07 2011 Initialization Sequence Completed
Tue Aug  9 11:06:36 2011 Replay-window backtrack occurred [2]
Tue Aug  9 11:06:38 2011 Replay-window backtrack occurred [3]
Tue Aug  9 11:08:20 2011 TLS: new session incoming connection from [AF_INET]184.22.62.14:1194
Tue Aug  9 11:08:20 2011 TLS: new session incoming connection from [AF_INET]184.22.62.14:1194
Tue Aug  9 11:08:20 2011 TLS: new session incoming connection from [AF_INET]184.22.62.14:1194
Tue Aug  9 11:08:20 2011 TLS: new session incoming connection from [AF_INET]184.22.62.14:1194
Tue Aug  9 11:08:20 2011 TLS: new session incoming connection from [AF_INET]184.22.62.14:1194
Tue Aug  9 11:08:22 2011 TLS: new session incoming connection from [AF_INET]184.22.62.14:1194

And this is what the server log said:

Code: Select all

Tue Aug  9 11:05:56 2011 CuraShare-****/190.112.***.***:34811 SENT CONTROL [CuraShare-****]: 'PUSH_REPLY,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ifconfig 10.8.0.4 255.255.255.0' (status=1)
Tue Aug  9 11:06:35 2011 CuraShare-****/190.112.***.***:34811 Replay-window backtrack occurred [2]
Tue Aug  9 11:08:00 2011 CuraShare-****/190.112.***.***:34811 Replay-window backtrack occurred [3]
Tue Aug  9 11:13:18 2011 CuraShare-****/190.112.***.***:34811 TLS: soft reset sec=-144 bytes=5641915/0 pkts=7558/0
Tue Aug  9 11:13:18 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:18 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:18 2011 CuraShare-****/190.112.***.***:34811 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS: Initial packet from [AF_INET]190.112.***.***:34811, sid=431b30b1 fe0367e9
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: reading acknowledgement record from packet
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: Unroutable control packet received from [AF_INET]190.112.***.***:34811 (si=3 op=P_ACK_V1)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: Unroutable control packet received from [AF_INET]190.112.***.***:34811 (si=3 op=P_ACK_V1)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS: tls_multi_process: killed expiring key
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:19 2011 CuraShare-****/190.112.***.***:34811 SIGUSR1[soft,tls-error] received, client-instance restarting
Tue Aug  9 11:13:21 2011 MULTI: multi_create_instance called
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 Re-using SSL/TLS context
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 Control Channel MTU parms [ L:1557 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 Data Channel MTU parms [ L:1557 D:1450 EF:57 EB:4 ET:0 EL:0 ]
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 Local Options hash (VER=V4): '2f3e190a'
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 Expected Remote Options hash (VER=V4): '0f816d6e'
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 TLS: Initial packet from [AF_INET]190.112.***.***:34811, sid=431b30b1 fe0367e9
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 TLS Error: TLS handshake failed
Tue Aug  9 11:13:21 2011 190.112.***.***:34811 SIGUSR1[soft,tls-error] received, client-instance restarting

The server and client are both in the same time zone, and differ about ~2.5 minutes in time.

Any clue why this is happening?