SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0001445: openvpn exits due to timeout after few minutes - MantisBT
MantisBT - Endian Firewall
View Issue Details
0001445Endian FirewallNetwork related (VPN, uplinks)public2008-11-11 17:512009-10-27 12:01
jzdrzalek 
peter-endian 
normalmajoralways
closedfixed 
2 
2.3 
0001445: openvpn exits due to timeout after few minutes
Server is 2.1.1, openvpn-2.0.9-0.endian5, openvpn-auth-2.1.0-1.endian2
Client is 2.2.1 openvpn-2.1-0.endian17, openvpn-auth-2.2.4-1.endian3

The Server and other clients (2.1 release) have stable vpns,
but the 2.2.1 client always dies with this error:

Nov 11 18:33:10 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:10 2008 OpenVPN 2.1_rc7 i586-endian-linux [SSL] [LZO2] [EPOLL] built on Oct 28 2008
Nov 11 18:33:10 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:10 2008 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm [^] for more info.
Nov 11 18:33:10 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:10 2008 LZO compression initialized
Nov 11 18:33:10 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:10 2008 UDPv4 link local: [undef]
Nov 11 18:33:10 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:10 2008 UDPv4 link remote: x.x.x.x:1194
Nov 11 18:33:11 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:11 2008 [127.0.0.1] Peer Connection Initiated with x.x.x.x:1194
Nov 11 18:33:12 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:12 2008 TUN/TAP device tap2 opened
Nov 11 18:33:12 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:12 2008 /sbin/ip link set dev tap2 up mtu 1500
Nov 11 18:33:12 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:12 2008 /sbin/ip addr add dev tap2 192.168.0.235/24 broadcast 192.168.0.255
Nov 11 18:33:12 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:12 2008 /usr/local/bin/dir.d-exec /etc/openvpn/ifup.client.d/ tap2 1500 1574 192.168.0.235 255.255.255.0 init
Nov 11 18:33:14 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:33:14 2008 Initialization Sequence Completed
Nov 11 18:34:41 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:34:41 2008 [127.0.0.1] Inactivity timeout (--ping-restart), restarting
Nov 11 18:34:41 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:34:41 2008 /sbin/ip addr del dev tap2 local 192.168.0.235 peer 255.255.255.0
Nov 11 18:34:41 Hamburg2 ECHamurg-Pala[2881]: RTNETLINK answers: Cannot assign requested address
Nov 11 18:34:41 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:34:41 2008 Linux ip addr del failed: shell command exited with error status: 2
Nov 11 18:34:41 Hamburg2 ECHamurg-Pala[2881]: Tue Nov 11 18:34:41 2008 Exiting

On server side:
Nov 11 18:33:10 hh-zentrale openvpn[29249]: x.x.x.x:32902 Re-using SSL/TLS context
Nov 11 18:33:10 hh-zentrale openvpn[29249]: x.x.x.x:32902 LZO compression initialized
Nov 11 18:33:11 hh-zentrale openvpn[29249]: x.x.x.x:32902 [ECHAMBURG] Peer Connection Initiated with x.x.x.x:32902
Nov 11 18:34:12 hh-zentrale openvpn[29249]: ECHAMBURG/x.x.x.x:32902 [ECHAMBURG] Inactivity timeout (--ping-restart), restarting
release 2.1 works well with 2.1 and release 2.2 works even better with 2.2, but 2.1 doesn't work with 2.2

All appliances are commercial versions, no CE versions are used.
needsfix
Issue History
2008-11-11 17:51jzdrzalekNew Issue
2008-11-11 17:51jzdrzalekAssigned To => peter-endian
2008-11-13 08:33peter-endianRelationship addedrelated to 0001460
2008-11-13 08:33peter-endianStatusnew => confirmed
2008-11-13 08:33peter-endianTag Attached: needsfix
2008-11-13 16:28peter-endianStatusconfirmed => resolved
2008-11-13 16:28peter-endianFixed in Version => 2.3
2008-11-13 16:28peter-endianResolutionopen => fixed
2009-10-27 12:01peter-endianStatusresolved => closed

There are no notes attached to this issue.