I'm a long time user of openvpn, but have a strange problem that I can't seem to resolve. I have a server (behind nat) and a client (behind nat).
The server config is:
port 1294
mode server
proto udp
dev tun
server 172.30.30.0 255.255.255.0
topology subnet
ifconfig-pool-persist ipp.txt
client-config-dir clients
ccd-exclusive
keepalive 30 120
tun-mtu 1440
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/keep.crt
key /etc/openvpn/easy-rsa/keys/keep.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
log-append /var/log/openvpn.log
status /var/run/openvpn/vpn.status 10
persist-key
persist-tun
user nobody
group nogroup
comp-lzo
verb 5
The client config is this:
client
dev tun
proto udp
remote xx.xx.xx.xx 1294
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
ca ca.crt
cert acgp-xen.crt
key acgp-xen.key
tun-mtu 1440
comp-lzo
log-append /var/log/openvpn.log
verb 2
The log on the server shows:
Tue Feb 16 13:13:18 2016 us=841336 MULTI: multi_create_instance called
Tue Feb 16 13:13:18 2016 us=841367 121.211.69.123:42751 Re-using SSL/TLS context
Tue Feb 16 13:13:18 2016 us=841375 121.211.69.123:42751 LZO compression initialized
Tue Feb 16 13:13:18 2016 us=841379 121.211.69.123:42751 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1440)
Tue Feb 16 13:13:18 2016 us=841435 121.211.69.123:42751 Control Channel MTU parms [ L:1482 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Feb 16 13:13:18 2016 us=841446 121.211.69.123:42751 Data Channel MTU parms [ L:1482 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Feb 16 13:13:18 2016 us=841468 121.211.69.123:42751 Local Options String: 'V4,dev-type tun,link-mtu 1482,tun-mtu 1440,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Tue Feb 16 13:13:18 2016 us=841475 121.211.69.123:42751 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1482,tun-mtu 1440,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Tue Feb 16 13:13:18 2016 us=841502 121.211.69.123:42751 Local Options hash (VER=V4): 'd81f5172'
Tue Feb 16 13:13:18 2016 us=841513 121.211.69.123:42751 Expected Remote Options hash (VER=V4): '739ddb62'
RTue Feb 16 13:13:18 2016 us=841537 121.211.69.123:42751 TLS: Initial packet from [AF_INET]121.211.69.123:42751, sid=52db6a93 5e28d833
WRRWRWRWWWWWRWWRWRWWWRWWWRWWRWWRWWWRWWRWRWWWRWRWWTue Feb 16 13:14:18 2016 us=723030 121.211.69.123:42751 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Feb 16 13:14:18 2016 us=723053 121.211.69.123:42751 TLS Error: TLS handshake failed
Tue Feb 16 13:14:18 2016 us=723124 121.211.69.123:42751 SIGUSR1[soft,tls-error] received, client-instance restarting
Which just repeats over and over.
Apparently, this could be a firewall issue, but clearly the client is talking to the server (hence the server activity in the log) and on the client a tcpdump shows packets from the server reaching us:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 192.168.255.2.34902 > xx.xx.xx.xx.1294: UDP, length 114
IP xx.xx.xx.xx.1294 > 192.168.0.2.34902: UDP, length 126
IP 192.168.255.2.34902 > xx.xx.xx.xx.1294: UDP, length 114
IP xx.xx.xx.xx.1294 > 192.168.0.2.34902: UDP, length 126
IP 192.168.255.2.34902 > xx.xx.xx.xx.1294: UDP, length 18
IP xx.xx.xx.xx.1294 > 192.168.0.2.34902: UDP, length 126
IP xx.xx.xx.xx.1294 > 192.168.0.2.34902: UDP, length 114
Both sides are debian linux:
Client using: 2.2.1-8+deb7u3
Server using: 2.3.4.5
I've tried wiping and re-building the server ca, certificates, etc and re-deploy to the client, but still the same behaviour.
If anyone can provide any clues, I'd be greatly appreciated, all I can currently think of is some strange firewall behaviour on the client side...
