Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Road Warrior One Hour Time Out

    Scheduled Pinned Locked Moved OpenVPN
    10 Posts 4 Posters 3.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      ghowey
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • N
        Nachtfalke
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • G
          ghowey
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            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).

            1 Reply Last reply Reply Quote 0
            • G
              ghowey
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • G
                  ghowey
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • A
                    ankaerith
                    last edited by

                    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
                    
                    
                    1 Reply Last reply Reply Quote 0
                    • G
                      ghowey
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • G
                        ghowey
                        last edited by

                        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!

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.