Open VPN Linux clients loose their ip address when connected

many clients connected to the open VPN obtain an IP address, but once they connect to Outlook and a connection is made with Exchange, they sometimes loose their ip address. Their adapter keeps searching for an IP address. I am not completly sure if this only happens when Outlook is initiated, but users usually only connect to the VPN to access email Outlook.

I dont know too much about openvpn, but I looked in the config file and noticed that openvpn is handing out IP addresses, not our internal DHCP server.

Remember this is very random, I will get 1 user a day having this issue out of about 25 users who use VPN.

I can post my config file if needed.

Thanks in advance
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Openvpn assigns his own internal IPs, because it implement a private subnet and a point-to-point connection between the server and each client.
In the config file you specify the pool and address class of the subnet. For each client, the server reserve 4 ip. Each ip is allocated to a specific client, but it can be reused if neccessary.
Can you provide the config file? and maybe some other information about the environment, for example, are the client  roadwarriors? which kind of connection they use? who assign the ip (apart the vpn server) ?
mancoiAuthor Commented:
I will have to get you the config file tomorrow or later on tonight.

I noticed that I had issues after my server went down hard one day. It was working perfectly.

each client is a road warrior. Even myself when working from home connected to the openvpn, I loose connection after about 20 minutes and my vpn connection starts looking for a new IP address, which it never finds.
It is strange that it will obtain an ip address and after 20 minutes, it will just out of no where start looking for another ip address, which it never succeeds.

My connection at home is a pretty good cable connection which I never have issues with the internet on any other computer in my house. I never loose connection here. I only have issues when connected to the openvpn.
what kind of authentication are you using? Pre shared key or X.509?
Have you seen the server logs?
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

mancoiAuthor Commented:
No I cannot find the server logs, where should I look?
I think I am using a pre shared key, but unsure of that.
How could I check?
If the server is a linux box, you should look in /var/log/openvpn.log .
if you are using an X.509 certificate, you should have some .crt file somewhere in the configuration directory.
mancoiAuthor Commented:
Yes I do have many .crt files in my openvpn directory.

I did see the server log file, but it is very large. I guess in the log will tell me what is the issue?
It could. You can filter out the lines you do not need in the logfile, taking just the lines just before and just after the loss-of-connection.

Just a side note, since I had a similar issue with clients that had the realtime clock not working properly. OpenVpn is very sensible to time changes. If the client had the time calendar updated (by user intervention or by automated clock update program), the connection can be taken down unexpectedly.

But you need the logfiles to tell what happens during the loss of connection...
mancoiAuthor Commented:
here are my findings in my log.

I am getting a bunch of the below, it is filled with just these lines:

AUTH-PAM: BACKGROUND: user 'jdacko' failed to authenticate: User not known to the underlying authentication module
Mon Apr 12 09:16:47 2010 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/share/openvpn/

I get these too randomly:

Thu Apr  8 15:23:18 2010 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/share/openvpn/
AUTH-PAM: BACKGROUND: user 'lgreenberg' failed to authenticate: User not known to the underlying authentication module

I am getting a few of these too:

Mon Apr  5 11:15:45 2010 WARNING: --ifconfig-pool-persist will not work with --duplicate-cn
Mon Apr  5 11:49:14 2010 MANAGEMENT: Socket bind failed on local address Address already in use
AUTH-PAM: Error signaling background process to exit
Mon Apr  5 11:49:31 2010 WARNING: --ifconfig-pool-persist will not work with --duplicate-cn
Mon Apr  5 11:53:32 2010 WARNING: Bad encapsulated packet length from peer (19025), which must be > 0 and <= 1576 -- please ensure that --tun-mtu or --link-mtu is equal on both$
Mon Apr  5 12:11:12 2010 WARNING: Bad encapsulated packet length from peer (19025), which must be > 0 and <= 1576 -- please ensure that --tun-mtu or --link-mtu is equal on both$

If you are using x.509 certificates, you should avoid using the same common name (CN) in each certificate. the CN is like the "username" in a user/password authentication. the WARNING you see just tells you that by using duplicate CN the server cannot "reserve" the ip for each user (is like a "lease" in a dhcp). In this case it must assign a new IP each time the client request a new connection. But if the connection are frequently falling, the ip pool can be consumed very fast.
So, try to remove the --duplicate-cn option for the server.
But be aware that if you are sharing the same cn (the same certificate), the server can only accept one connection from each cn at a time, so the second arriving user cannot authenticate. In this case you should provide new certificates to each user.
I do not know if this solve your issue (I am not sure, but in effect that could explain your problem), but I think you should check.

Hope that helps.  

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mancoiAuthor Commented:
I just commented out the duplicate-cn option  and I was unable to connect to the VPN.

You have many duplicate common names, i.e. you are sharing the same certificate between many users.
You should create new certificates with different cn, and send it to the users.
But I repeat, I do not know if this can solve the original issue.
mancoiAuthor Commented:
I will keep monitoring the event logs, thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.