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

    PP2T VPN client weirdness

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    27 Posts 4 Posters 12.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.
    • P
      pwnell
      last edited by

      Under linux I have configured a 30 second lcp echo request, the VPN still dies after a minute or two if I do not actively transfer data.

      1 Reply Last reply Reply Quote 0
      • Y
        yaw
        last edited by

        I'm seeing the same thing here on my end. If I leave it without sending packets the firewall starts blocking GRE packets:

        [blocked] Dec 11 08:08:30 WAN  A.A.A.A    B.B.B.B  GRE
        Where A is the remote VPN server IP, and B is the pfsense box IP.

        It ONLY starts blocking these GRE packets if it sits for a little while without sending packets. As long as pfsense keeps sending packets then it'll never start blocking GRE. However, the game is over once it starts.

        If I add a rule to allow all GRE traffic on the WAN interface then those errors are surpressed. The firewall logs don't show anything being blocked. However, the problem still exists. All VPN traffic stops and I must disconnect and reconnect to fix it.

        I'm running 2.0-BETA4 (i386) built on Tue Dec 7 06:58:02 EST 2010

        1 Reply Last reply Reply Quote 0
        • P
          pwnell
          last edited by

          I agree with yaw - exactly the same behaviour.  Furthermore, if I replace pfSense with my DLink WiFi router, the problem goes away and my PPTP connections stay alive without needing any keep alive traffic.

          1 Reply Last reply Reply Quote 0
          • Y
            yaw
            last edited by

            Yep.. something odd going on here. I never had this problem with version 1.2.3

            1 Reply Last reply Reply Quote 0
            • P
              pwnell
              last edited by

              Also not with pfSense 2.0 BETA3 from June this year I think.

              1 Reply Last reply Reply Quote 0
              • D
                Darkk
                last edited by

                Yes I am seeing this exact same issue with the beta snapshots as of late.  I tried a few things and had to revert back to the 1.2.3 release until it gets sorted out.  This will be a problem for folks who PfSense at home offices and corporations.

                So any ideas would be greately apprecaitedl.

                Darkk

                1 Reply Last reply Reply Quote 0
                • P
                  pwnell
                  last edited by

                  Found this: http://forum.pfsense.org/index.php/topic,29427.0.html, and tried adding the two NAT rules for TCP/1732 and GRE.  What do you know - now it works.  But I am confused - I thought this was fixed already? Secondly, obviously the NAT rules are only a temporary solution as I have multiple clients needing PPTP access behind the firewall.

                  (I say it worked because I managed 17 minutes and counting of idle PPTP traffic without being disconnected).

                  1 Reply Last reply Reply Quote 0
                  • Y
                    yaw
                    last edited by

                    Yeah.. I have multiple clients here also.. not going to work.

                    I wonder if the fix always had this problem. I bet nobody let their connection sit idle long enough to test.

                    1 Reply Last reply Reply Quote 0
                    • P
                      pwnell
                      last edited by

                      Mine will timeout like that within 45 seconds….

                      Grabbing a coffee?

                      1 Reply Last reply Reply Quote 0
                      • Y
                        yaw
                        last edited by

                        haha.. good point. Mine is rather quick also. Who knows then.

                        1 Reply Last reply Reply Quote 0
                        • D
                          Darkk
                          last edited by

                          Wouldn't it be easier to have it automatically create a Dead Peer Detection routine just like IPSec to keep it alive?

                          Darkk

                          1 Reply Last reply Reply Quote 0
                          • P
                            pwnell
                            last edited by

                            I think the problem is that the state table gets messed up somehow and the reply packets do not make it back to the NAT-ed host.

                            1 Reply Last reply Reply Quote 0
                            • P
                              pwnell
                              last edited by

                              Any news on this?

                              1 Reply Last reply Reply Quote 0
                              • P
                                pwnell
                                last edited by

                                Still seems broken in this build:

                                2.0-BETA4 (i386)
                                built on Sat Dec 18 09:51:58 EST 2010

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pwnell
                                  last edited by

                                  Just checked with

                                  2.0-BETA5 (i386)
                                  built on Mon Jan 3 13:22:20 EST 2011

                                  Still the same.  Can connect to any PPTP VPN just fine, but if I do not continuously send traffic the link goes half dead - I can send packets but never receive anything.

                                  Please this is very important, any insights?

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