[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] load balancing with a wee problem


  • Subject: Re: [Openvpn-users] load balancing with a wee problem
  • From: Sebastian Perkins <sperkins@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 23 Jan 2008 09:21:15 +0100

Sebastian Perkins a écrit :
> Hello,
>
> I've tried remap-usr1 SIGHUP on the client's .conf but not better. 
> When the tunnel drops, there's just a hard reset instead of a soft 
> reset in the log (cf line 8)
>
> The logs show that the client loses the connexion, throughs a few 
> errors and... no more tunnel. Worse still... no openvpn process !
>
> Here is the log (verbose bumped up to 4 or 5) with a few ip's/keys 
> omitted for privacy of a 2.0.7 client connecting to 2.1rc2 + deleted a 
> few lines to stay under the 40k mailing list limit :o) : there seems 
> to be permission problems at the end. Maybe the restart pause could be 
> increased ? :
>
> PS : should I revert back to 2.0.9 server ? the 2.1rc2 is yum standard 
> on fedora core 6.
>
> Many thanks,
>
> Jan 20 06:06:52 albertville openvpn[16219]: [mainserver] Inactivity 
> timeout (--ping-restart), restarting
> Jan 20 06:06:52 XXX openvpn[16219]: TCP/UDP: Closing socket
> Jan 20 06:06:52 XXX openvpn[16219]: /sbin/ip route del 192.x.x.x/24
> Jan 20 06:06:52 XXX openvpn[16219]: ERROR: Linux route delete command 
> failed: shell command exited with error status: 2
> Jan 20 06:06:52 XXX openvpn[16219]: /sbin/ip route del 10.y.y.y/24
> Jan 20 06:06:52 XXX openvpn[16219]: ERROR: Linux route delete command 
> failed: shell command exited with error status: 2
> Jan 20 06:06:52 XXX openvpn[16219]: Closing TUN/TAP interface
> Jan 20 06:06:52 XXX openvpn[16219]: SIGHUP[soft,ping-restart] 
> received, process restarting
> Jan 20 06:06:52 XXX openvpn[16219]: Current Parameter Settings:
> Jan 20 06:06:52 XXX openvpn[16219]: config = 'XXX.conf'
>
(a few lines...)

> Jan 20 06:06:53 XXX openvpn[16219]: auth_user_pass_file = '[UNDEF]'
> Jan 20 06:06:53 XXX openvpn[16219]: OpenVPN 2.0.7 
> i386-redhat-linux-gnu [SSL] [LZO] [EPOLL] built on Apr 12 2006
> Jan 20 06:06:53 XXX openvpn[16219]: Restart pause, 2 second(s)
> Jan 20 06:06:55 XXX openvpn[16219]: IMPORTANT: OpenVPN's default port 
> number is now 1194, based on an official port number assignment by 
> IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
> Jan 20 06:06:55 XXX openvpn[16219]: WARNING: No server certificate 
> verification method has been enabled. See 
> http://openvpn.net/howto.html#mitm for more info.
> Jan 20 06:06:55 XXX openvpn[16219]: Cannot load private key file 
> XXX.key: error:0200100D:system library:fopen:Permission denied: 
> error:20074002:BIO routines:FILE_CTRL:system lib: error:140B0002:SSL 
> routines:SSL_CTX_use_PrivateKey_file:system lib
> Jan 20 06:06:55 XXX openvpn[16219]: Error: private key password 
> verification failed
> Jan 20 06:06:55 XXX openvpn[16219]: Exiting
>
>
> -- 
> Sebastian Perkins
> Responsable Informatique
> sperkins@xxxxxxxxxxxxxxxxxx
>
>   
> Darren Loher a écrit :
>>
>> Something else I’ve seen is that a NAT-FW will timeout your 
>> port-translation pair. This sometimes can be an absolute timeout, 
>> meaning it will shut off your traffic after some period of time even 
>> if the session is actively sending traffic. (killing long lived sessions)
>>
>> Openvpn attempts to reuse the same port pair on a soft-reset. You can 
>> change this to a hard-reset though, which will cause a diff port pair 
>> to be used.
>>
>> To enable this, try doing this on your client:
>>
>> remap-usr1 SIGHUP
>>
>> When you tunnel gets timed out, it should automatically attempt to 
>> restart the tunnel, this time using a different port-pair.
>>
>> -Darren
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Sebastian Perkins [mailto:sperkins@xxxxxxxxxxxxxxxxxx]
>> *Sent:* Tuesday, January 15, 2008 8:34 AM
>> *To:* Darren Loher
>> *Cc:* openvpn-users@xxxxxxxxxxxxxxxxxxxxx
>> *Subject:* Re: [Openvpn-users] load balancing with a wee problem
>>
>> on the client .conf the only persist options are :
>> persist-key
>> persist-tun
>>
>>
>>
>> Sebastian Perkins
>> Responsable Informatique
>> sperkins@xxxxxxxxxxxxxxxxxx
>>
>> ----- Message Original -----
>> De: "Darren Loher" <dloher@xxxxxxxxxxxx>
>> A: "Sebastian Perkins" <sperkins@xxxxxxxxxxxxxxxxxx>, 
>> openvpn-users@xxxxxxxxxxxxxxxxxxxxx
>> Sent: mardi 15 janvier 2008 16 h 27 (GMT+0100) Europe/Berlin
>> Sujet: RE: [Openvpn-users] load balancing with a wee problem
>>
>>
>> Try removing “persist routes” if you are using that on the client 
>> configuration.
>>
>> ------------------------------------------------------------------------
>>
>> *From:* openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx 
>> [mailto:openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx] *On Behalf Of 
>> *Sebastian Perkins
>> *Sent:* Tuesday, January 15, 2008 3:20 AM
>> *To:* openvpn-users@xxxxxxxxxxxxxxxxxxxxx
>> *Subject:* [Openvpn-users] load balancing with a wee problem
>>
>> Hello,
>>
>> We are using openvpn tunnel mode with 2 servers + 22 clients 
>> interconnecting our offices. Works great !
>>
>> Clients are openvpn 2.0.7 -> 2.0.9 (fedora core 3 or 4) and serveurs 
>> are FC5 + openvpn 2.1rc2 (from the yum repository).
>>
>> The 2 servers are used for load balancing : each is connected to an 
>> ADSL modem. The clients connect with 2 remote entries + resolve 
>> random to balance. Actually this solution is also quite fault tolerant.
>>
>> So far so good, our problem comes from a client's light broadband 
>> failure (ie under 20min) : the client's tunnel doesn't come back up.
>>
>> I've gone through the logs, it seems that :
>> Client A is connected to Server 1
>> broadband goes down
>> broadband goes up
>> Client A reconnects using "remote random" => connects to server 2
>> Server 1 issues a reconnection ("ping restarting...")
>>
>> Then I get "connnexion refused" errors...
>>
>> If I issue "service openvpn restart" on the client, everything works 
>> fine. Server side, all other tunneled connexions are fine and do not 
>> experience any problems. Clients that come down are in 2.0.7 or 2.0.9...
>>
>> I can post the configs I you want, but my idea is that the servers 
>> are using "keepalive" options, just like the clients : should I just 
>> use keepalive on the clients ? Or am I wrong ?
>>
>> Thanks in advance,
>>
>> Sebastian Perkins
>> Responsable Informatique
>> sperkins@xxxxxxxxxxxxxxxxxx
>>

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users