|
|
Dear,
I would like to share this with you. The majority of VPN lockups
problem is solved now. It was neither NAT collision nor port tearing
like Jason's suggestion.
We have an auth-user-pass-verify option enabled in the server
configuration which we use to authentiate our clients against an
external OpenLDAP server.
After deep investigations we found that the problem is the LDAP server
is not responding too fast and sometimes suffers a lockup. While at the
same time the client asks, approximately every two minutes and 5
seconds even if we have "auth-retry none" in the server configuration,
the server to re-authenticate and halts any traffic during this time
untill it gets a reply.
We worked around it by returning an "always successfull" reply to the VPN server. This solved the majority of clients.
We are still having a problem with people who are using Avaya's soft
phones. During normal VPN operation the call is in peer-to-peer mode
and once the client asks for re-autherntication; the softphone hears
nothing but silence and we find that the softphone is talking with
Avaya's MedPro only and cannot get back to the session with the callee.
Does the client disable the TUN adapter? or does not accept any traffic
while waiting for re-authentication that causes the softphone to think
the client is disconnected and hence goes back to the MedPro?
Regards
--
Sameh Attia
Information Security Manager
Red Hat Certified Engineer
TE Data
--
dc -e '603178305900664311156641389051003470569569613466992253686426210705237258P'
On 2/13/06, Jason Haar <Jason.Haar@xxxxxxxxxxxxx> wrote:
Sameh Attia wrote:
> This might not be your case. But we are facing this same issue since
> we transported our HQ to another new location while leaving the VPN
> server in the old place.
>
> The only difference here is VPN clients are now NATed before they
> reach the VPN server. The number of clients is about 150. I think it
> might be some sort of source port collision?
That shouldn't be a problem - but of course is entirely dependent on
your NAT device. As there are 65,000 ports, 150 being allocated to VPN
connections shouldn't mean you've run out - but only your NAT device can
really answer this question...
As you using UDP? If so, maybe the NAT device is tearing down the UDP
connection faster that OpenVPN expects.
e.g.
Time:0sec client -> UDP --> NAT -> srcport=30000 -> server-port-1194
(everyone happy)
...later....
client -> 30sec quiet -> NAT-times-out-above-UDP "session/tunnel"
Time:40sec server-port-1194 -> dstport=30000 -> NAT - "Port Unreachable"
If this is happening, either
a> increase UDP NAT timeout to be larger than OpenVPN "ping" timeout
b> decrease OpenVPN ping timeout to something smaller that the NAT timeout
c> use TCP. Doesn't suffer from this particular NAT timeout issue
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|