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

    IPSec Tunnel dies but shows as up still

    Scheduled Pinned Locked Moved 1.2.3-PRERELEASE-TESTING snapshots - RETIRED
    20 Posts 8 Posters 13.2k 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.
    • A
      ankaerith
      last edited by

      I updated to RC1 and all of my IPSec site-to-site tunnels die and can't recover without restarting IPSec.  Please see my above post for more details.

      I am not using NAT-T.

      I tried enabling dead peer detection.  It didn't help.

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

        I have only 1 site to site tunnel. I have to stop and restart ipsec after a reboot, but once I do this, it stays up until next reboot. I think that might have been due to another problem with my provider and a router port problem though that I have only had once. I will find out next time its down. (which might be a very long time)

        Cheers guys.

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

          I finally gave up on the 1.2.3 snapshots.  I rolled back to 1.2.2 and my tunnels came back up and have been rock solid since.  I made zero configuration changes.  I simply pointed the console update URL to the 1.2.2 full upgrade download.

          1.2.3 had fixed some issues I'd had with some network cards, but those were pretty minor compared to non-functional IPSec.

          If any developer wants help testing or debugging this issue I'd be happy to reinstall the latest snapshot and work with them on it.  I've got access to PIXs running 6.3.5 and 8.0.4 and a Concentrator 3005.

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

            @kapara:

            Is anyone having a good experience with IPSEC lan to LAN with 1.2.3?

            No issues here with 1.2.3 RC1 and Astaro 7.4 with IPsec VPNs.  The Astaro box is even behind a NAT machine (a pfSense box ;-) so NAT-T appears to be working well, too.

            We just got this particular setup up and running a couple days ago, no issues the entire time so far.

            1 Reply Last reply Reply Quote 0
            • R
              rwalker
              last edited by

              Everyone that has posted above needs to update whether they are using parallel tunnels or not (meaning you have more than one network so a tunnel for each network).  This problem existed in 1.2.2 and I am curious whether it has gotten worse or better.

              Thanks,
              Roy

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

                @rwalker:

                Everyone that has posted above needs to update whether they are using parallel tunnels or not (meaning you have more than one network so a tunnel for each network).  This problem existed in 1.2.2 and I am curious whether it has gotten worse or better.

                I'm using 1.2.3 RC1 in a multi-tunnel setup with no problems for about a week now.

                The pfSense side has two subnets, the other side (Astaro) has one.

                The only issue I see is that the IPsec status screen shows the VPNs in state yellow instead of green, and one of the tunnels is missing the source network, yet the tunnels are working fine.  They have been yellow for at least a couple days.

                See the attached picture.

                Green is the pfSense endpoint IP.
                Red is the Astaro endpoint IP.
                Pink is the Astaro LAN network
                Blue is the pfSense LAN network

                Note the missing LAN network in the first listed VPN and how the status is yellow on both.  But both VPNs are functioning properly.

                IPsec-Status.png
                IPsec-Status.png_thumb

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

                  I am connecting to 3 Cisco PIXs with 6 tunnels.

                  PIX 1: 3 tunnels
                  PIX 2: 2 tunnels
                  PIX 3: 1 tunnel

                  PIX config:
                  crypto ipsec transform-set myset esp-3des esp-sha-hmac
                  crypto map outside_map 40 ipsec-isakmp
                  crypto map outside_map 40 match address outside_cryptomap_40
                  crypto map outside_map 40 set pfs group2
                  crypto map outside_map 40 set peer 1.1.1.1
                  crypto map outside_map 40 set transform-set myset
                  isakmp key ******** address 1.1.1.1 netmask 255.255.255.255
                  isakmp identity address
                  isakmp policy 42 authentication pre-share
                  isakmp policy 42 encryption 3des
                  isakmp policy 42 hash md5
                  isakmp policy 42 group 2
                  isakmp policy 42 lifetime 86400
                  isakmp policy 62 authentication pre-share
                  isakmp policy 62 encryption 3des
                  isakmp policy 62 hash sha
                  isakmp policy 62 group 2
                  isakmp policy 62 lifetime 86400

                  PFSense:

                  Phase 1:
                  Negotiation mode: MAIN
                  My identifier: MY IP
                  Encryption algorithm: 3DES
                  Hash algorithm: SHA1
                  DH key group: 2
                  Lifetime: 28800
                  Authentication method: pre-shared

                  Phase 2:
                  Protocol: ESP
                  Encryption algorithm: 3DES
                  Hash algorithms: SHA1 , MD5
                  PFS key group: 2
                  Lifetime: 86400

                  Works perfectly on 1.2.2.

                  1 Reply Last reply Reply Quote 0
                  • R
                    rwalker
                    last edited by

                    The issue is only between pfSense <-> pfSense.  Between any other device I have tested it works without a problem (parallel tunnels or not).  I have now upgraded a few of our firewalls to 1.2.3RC1, so will see what happens.

                    Roy

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

                      Well just tested with NAT-T enabled and mine is now working!!! Thanks guys, truly wonderful.

                      1 Reply Last reply Reply Quote 0
                      • S
                        sigma
                        last edited by

                        At the moment I use 1.2.3 RC2 and have also a similar problem, but not the same as written here. I only have troubles to access over VPN if I'm on the WLAN port. No problems at all on the LAN port. On the other side an old ZyWall 30W is working.

                        I now disabled NAT-T because it's the only hint I found here. So I cann tell more about that tomorrow or so.

                        After a reboot I have again acces over vpn from WLAN for a few hours until it's broken again. And as I told, after it is brolen on WLAN it works fine in LAN.

                        Sigma

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

                          We were trying ipsec-tools 0.8 during that timeframe to fix a number of DPD issues with tunnels not re-negotiating.

                          This proved to cause lot's of issues with parallel tunnels.

                          So we backed out the change and went back to 0.7.2. We will be merging 0.7.3 soon which was just released.

                          It has a few small fixes but unlikely to break things.

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