[Openvpn-users] Connection timed out (WSAETIMEDOUT) (code=10060)

[Stefan Bauer]

Dear Developers & Users,

we're facing a very strange issue since several weeks and this is driving us and our users crazy.


Workers are on Network 172.20.200.0/25 and want to use OpenVPN to Head-Office
to access Secured-Hosts - Version is the latest stable

Head-Office-OpenVPN-SErver is 192.168.200.6 - Version 2.1~rc11-1

More or less randomly (around 50 Minutes, 2 hours, with slight difference in time) the openvpn-connections
are terminated of all workers in branch-office. The Ipsec-Tunnel is stable all the time so
it's only related to openvpn.

Network is like:

# this is the connection from the workers over the established ipsec-connection
Workers -----------> OpenVPN over TCP ----------> Head-Office ----> Secured-Hosts

# this is the ipsec-connection from branch-to-head
Branch-Office <----- IPSEC-TUNNEL(Cisco ASA 5505) -------------> Head-Office(StrongSWAN)

The Cisco ASA 5505 is the default gateway for the workers.


Logs & Configs attached below.


Any help is greatly appreciated - wen ran out of ideas.

thank you very much in advance

Stefan




Openvpn client-config is:

tls-client
client
dev tun

proto tcp
remote 192.168.200.6 2000

#Nobind for Double VPN Connection#
nobind

#Radius Auth Settings
auth-user-pass
auth-nocache

reneg-sec 86400

#Crypto and Certificate Settings
ca certs\\island\\cacert.pem

cipher AES-128-CBC

persist-key
persist-tun

#Connection Optimization
comp-lzo
keepalive 10 600

verb 3
ns-cert-type server

#Win Vista/7 Options
route-method exe
route-delay 2



OpenVPN Server-Config:

mode server
local 192.168.200.6
proto tcp
port 2000
dev tun0

plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn

reneg-sec 86400

client-cert-not-required
username-as-common-name

duplicate-cn

tls-server
ca /var/csn/ca/cacert.pem
crl-verify /var/csn/crl/csn_crl.pem
cert /var/csn/ca/servercert.pem
key /var/csn/ca/serverkey.pem
dh /var/csn/ca/dh2048.pem

cipher AES-128-CBC

persist-key
persist-tun

server 172.20.124.0 255.255.254.0
client-config-dir /etc/openvpn/clients/client_conf
persist-local-ip
persist-remote-ip

push "redirect-gateway"

push "dhcp-option DNS 172.20.1.45"
push "dhcp-option DNS 172.20.1.2"
push "dhcp-option DOMAIN intern.company.com"
push "dhcp-option WINS 172.20.1.2"

#Additional Routes for Internal networks
#Default Internal Network
push "route 172.20.0.0 255.255.128.0 net_gateway"
#branch office
push "route 172.20.200.0 255.255.255.0 net_gateway"



#Connection Optimization
keepalive 10 600
comp-lzo

#Automatic Disconnect if less then 150 KByte is transmitted within 2 hour#
inactive 7200 153600

#Run OpenVPN Server as nobody
user nobody
group nogroup

#Enable Management Interface
management 192.168.200.6 5555 pass.txt

#Logging
status /var/log/openvpn/csn_radius_tcp_2000.stat
log-append /var/log/openvpn/csn_radius_tcp_2000.log
verb 4

[Jan Just Keijser]

Hi Stefan,

Post by Stefan Bauer
Dear Developers & Users,
we're facing a very strange issue since several weeks and this is driving us and our users crazy.
Workers are on Network 172.20.200.0/25 and want to use OpenVPN to Head-Office
to access Secured-Hosts - Version is the latest stable
Head-Office-OpenVPN-SErver is 192.168.200.6 - Version 2.1~rc11-1
More or less randomly (around 50 Minutes, 2 hours, with slight difference in time) the openvpn-connections
are terminated of all workers in branch-office. The Ipsec-Tunnel is stable all the time so
it's only related to openvpn.
# this is the connection from the workers over the established ipsec-connection
Workers -----------> OpenVPN over TCP ----------> Head-Office ----> Secured-Hosts
# this is the ipsec-connection from branch-to-head
Branch-Office <----- IPSEC-TUNNEL(Cisco ASA 5505) -------------> Head-Office(StrongSWAN)
The Cisco ASA 5505 is the default gateway for the workers.

can you comment out the server config line
inactive 7200 153600

? I just want to rule out that this line is causing the disconnects...

Also, 2.1rc11 is quite old, can you upgrade the server to at least 2.1.4
, preferably 2.2.2 ?

HTH,

JJK

Post by Stefan Bauer
Logs & Configs attached below.
Any help is greatly appreciated - wen ran out of ideas.
thank you very much in advance
Stefan
tls-client
client
dev tun
proto tcp
remote 192.168.200.6 2000
#Nobind for Double VPN Connection#
nobind
#Radius Auth Settings
auth-user-pass
auth-nocache
reneg-sec 86400
#Crypto and Certificate Settings
ca certs\\island\\cacert.pem
cipher AES-128-CBC
persist-key
persist-tun
#Connection Optimization
comp-lzo
keepalive 10 600
verb 3
ns-cert-type server
#Win Vista/7 Options
route-method exe
route-delay 2
mode server
local 192.168.200.6
proto tcp
port 2000
dev tun0
plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn
reneg-sec 86400
client-cert-not-required
username-as-common-name
duplicate-cn
tls-server
ca /var/csn/ca/cacert.pem
crl-verify /var/csn/crl/csn_crl.pem
cert /var/csn/ca/servercert.pem
key /var/csn/ca/serverkey.pem
dh /var/csn/ca/dh2048.pem
cipher AES-128-CBC
persist-key
persist-tun
server 172.20.124.0 255.255.254.0
client-config-dir /etc/openvpn/clients/client_conf
persist-local-ip
persist-remote-ip
push "redirect-gateway"
push "dhcp-option DNS 172.20.1.45"
push "dhcp-option DNS 172.20.1.2"
push "dhcp-option DOMAIN intern.company.com"
push "dhcp-option WINS 172.20.1.2"
#Additional Routes for Internal networks
#Default Internal Network
push "route 172.20.0.0 255.255.128.0 net_gateway"
#branch office
push "route 172.20.200.0 255.255.255.0 net_gateway"
#Connection Optimization
keepalive 10 600
comp-lzo
#Automatic Disconnect if less then 150 KByte is transmitted within 2 hour#
inactive 7200 153600
#Run OpenVPN Server as nobody
user nobody
group nogroup
#Enable Management Interface
management 192.168.200.6 5555 pass.txt
#Logging
status /var/log/openvpn/csn_radius_tcp_2000.stat
log-append /var/log/openvpn/csn_radius_tcp_2000.log
verb 4
------------------------------------------------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
------------------------------------------------------------------------
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Stefan Bauer]

-----Ursprüngliche Nachricht-----

Post by Jan Just Keijser
can you comment out the server config line
  inactive 7200 153600
? I just want to rule out that this line is causing the disconnects...
Also, 2.1rc11 is quite old, can you upgrade the server to at least 2.1.4 ,
preferably 2.2.2 ?

Hi Jan Just,

thank you for your input. We removed the inactive-setting - restarted the server and tested.
Unfortunately no change - still the same random disconnects.

Best Regards

Stefan

[Jan Just Keijser]

-----UrsprÃŒngliche Nachricht-----

Post by Jan Just Keijser
can you comment out the server config line
inactive 7200 153600
? I just want to rule out that this line is causing the disconnects...
Also, 2.1rc11 is quite old, can you upgrade the server to at least 2.1.4 ,
preferably 2.2.2 ?

Hi Jan Just,
thank you for your input. We removed the inactive-setting - restarted the server and tested.
Unfortunately no change - still the same random disconnects.

strange... another thing to try (for troubleshooting) is to disable key
renegotation; add
reneg-sec 0 0
to the server config and wait; I don't expect that it will make much of
a difference but troubleshooting an issue like this normally is a case
of 'eliminating all other options'

HTH,

JJK

[Stefan Bauer]

-----Ursprüngliche Nachricht-----

strange... another thing to try  (for troubleshooting) is to disable key
renegotation; add
  reneg-sec 0 0
to the server config and wait; I don't expect that it will make much of a
difference but troubleshooting an issue like this normally is a case of
'eliminating all other options'

Good Morning list,

it seems, that we found a solution but would like to hear your explanation why that solves our problem:

We build a testserver and changed TCP to UDP. Since more than 18 hours - we're not having a single disconnect.

Any ideas on that?


Stefan