Road Warrior One Hour Time Out



  • First of all let me say Thank You for a great package. I was using OpenVPN on Windows Servers behind a wired gateway for site to site and road warrior configurations. The included OpenVPN wizards in pfSense release 2.0.1 make the configuration very straight forward and quick. The firewall capabilities of pfSense are very flexible and have more than met our meager needs. I need to ask one question, and I am sure it is a configuration over site on my part. As I mentioned we have two sites with a peer-to-peer connection using pre-shared keys with OpenVPN, and a road-warrior server at the main site with OpenVPN. Both sites are visible to each other and to the road warriors. The only hiccup I have is that the road-warrior connection times out at one hour, irregardless of whether the connection is active or not. The logs reveal no problems. Can anyone shed any insight on a possible configuration that is associated with this time out?

    Thanks, Greg Howey.



  • Do you have any shedules or traffic shaper/layer7 enabled ?
    In general it should not timeout.



  • No schedules or traffic shaping enabled. Site to site is rock solid with no interruptions, but road warrior configuration consistently times out at one hour. "keepalive" options seem to have no effect.



  • Is it all clients, or only one? My first guess is the client is behind some flaky NAT box that doesn't handle long lived UDP sessions well, just drops them after an hour. That'd likely only be if it's specific to a single client (unless they're all behind the same kind of NAT).



  • All clients, not just the one. I am not sure of all but the config I use from home to administer the domain is behind pfSense on an old PIII machine.



  • Is there anything upstream of the server-side? DSL modem, other router, etc.?



  • The pfSense "Appliance" is directly behind a broadband cable modem, and nothing else. I find it doubtful that this could be an issue, but I have learned in my experience to never say no! I would gladly post my configuration files if you would like to take a look. They are pretty straight forward, I used the OpenVPN Wizard in pfSense for creation of the config.



  • I see the same issue.  Unfortunately, there isn't anything too helpful in the system logs, but here is what I do see:

    
    Feb 27 10:49:27	openvpn: user joeuser authenticated
    Feb 27 10:49:25	openvpn: Found certificate /C=US/ST=California/L=Here/O=There/emailAddress=joeuser@somewhere.com/CN=joeuser with depth 0
    Feb 27 10:49:25	openvpn: Found certificate /C=US/ST=California/L=Here/O=There/emailAddress=joeuser@somewhere.com/CN=internal-ca with depth 1
    Feb 27 09:49:13	openvpn: user joeuser authenticated
    Feb 27 09:49:11	openvpn: Found certificate /C=US/ST=California/L=Here/O=There/emailAddress=joeuser@somewhere.com/CN=joeuser with depth 0
    Feb 27 09:49:11	openvpn: Found certificate /C=US/ST=California/L=Here/O=There/emailAddress=joeuser@somewhere.com/CN=internal-ca with depth 1
    Feb 27 08:49:02	openvpn[35469]: joeuser/1.2.3.4:2337 send_push_reply(): safe_cap=960
    Feb 27 08:49:00	openvpn[35469]: joeuser/1.2.3.4:2337 MULTI_sva: pool returned IPv4=172.16.1.6, IPv6=94da:xxxx:xxxx:xxxx:xxxx:xxxx:xxx
    Feb 27 08:49:00	openvpn[35469]: 1.2.3.4:2337 [joeuser] Peer Connection Initiated with [AF_INET]1.2.3.4:2337
    Feb 27 08:49:00	openvpn: user joeuser authenticated
    
    


  • After more investigation it would seem that the data channel renegotiates keys every hour. Apparently something is awry, this is when my connection drops and prompts me to enter my credentials again. I notice in another post when the "auth-nocache" was removed from the client configuration the issue was resolved. I will give that a try, but I have found that if you add "reneg-sec 0" to client and server configurations my connection never times out. Will post my results concerning removing "auth-nocache" very soon.



  • Removing "auth-nocache" from client configuration files indeed resolved the issue. Although encouraged by OpenVPN to use this option in the client configuration apparently when the data channel renegotiates the keys cached credentials are needed or re-authorization is required to keep the connection active! Thank You for the fix Wasca!


Log in to reply