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

    IPSEC tunnels all dropping at random times after upgrade from 1.2.3 to 2.0

    Scheduled Pinned Locked Moved IPsec
    7 Posts 3 Posters 18.9k 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
      afinkinfotech
      last edited by

      Our VPN tunnels drop at random intervals.  When this happens if we click save to update policy then they all come back.

      We have 4 tunnels two going to pfsense 1.2.3, one going to a Cisco RVS400 and one going to a SnapGear router.

      Here is the relevant part of our log with the ips removed and labeled with type of router.  If anyone has seen this before or knows of a fix please let us know.  Thanks in Advance.

      Aug 25 10:00:02 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3rc1.ip[500]
      Aug 25 10:00:02 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:02 colbert racoon: ERROR: phase1 negotiation failed due to send error. 1686ec4ab8a3549a:0000000000000000
      Aug 25 10:00:02 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:07 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:07 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:07 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:07 colbert racoon: ERROR: phase1 negotiation failed due to send error. 47a8c87827cc143a:0000000000000000
      Aug 25 10:00:07 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:09 colbert racoon: INFO: IPsec-SA request for snapGear.ip queued due to no phase1 found.
      Aug 25 10:00:09 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>snapGear.ip[500]
      Aug 25 10:00:09 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:09 colbert racoon: ERROR: phase1 negotiation failed due to send error. e136782a40a70ee2:0000000000000000
      Aug 25 10:00:09 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:10 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:10 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:10 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:10 colbert racoon: ERROR: phase1 negotiation failed due to send error. aad3d96b46ffe46d:0000000000000000
      Aug 25 10:00:10 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:15 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:15 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:15 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:15 colbert racoon: ERROR: phase1 negotiation failed due to send error. 08b7129323fd82ae:0000000000000000
      Aug 25 10:00:15 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:18 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:18 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:18 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:18 colbert racoon: ERROR: phase1 negotiation failed due to send error. 59d9186201c82b6d:0000000000000000
      Aug 25 10:00:18 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:18 colbert racoon: INFO: IPsec-SA request for ciscoRVS400.ip queued due to no phase1 found.
      Aug 25 10:00:18 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>ciscoRVS400.ip[500]
      Aug 25 10:00:18 colbert racoon: INFO: begin Identity Protection mode.
      Aug 25 10:00:18 colbert racoon: ERROR: phase1 negotiation failed due to send error. 432264a59b93befb:0000000000000000
      Aug 25 10:00:18 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:22 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:22 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:22 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:22 colbert racoon: ERROR: phase1 negotiation failed due to send error. ea49983f6d509512:0000000000000000
      Aug 25 10:00:22 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:24 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3rc1.ip queued due to no phase1 found.
      Aug 25 10:00:24 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3rc1.ip[500]
      Aug 25 10:00:24 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:24 colbert racoon: ERROR: phase1 negotiation failed due to send error. 6b0573448d3e6426:0000000000000000
      Aug 25 10:00:24 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:28 colbert racoon: INFO: IPsec-SA request for ciscoRVS400.ip queued due to no phase1 found.
      Aug 25 10:00:28 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>ciscoRVS400.ip[500]
      Aug 25 10:00:28 colbert racoon: INFO: begin Identity Protection mode.
      Aug 25 10:00:28 colbert racoon: ERROR: phase1 negotiation failed due to send error. 09a4b0472d308e01:0000000000000000
      Aug 25 10:00:28 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:30 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:30 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:30 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:30 colbert racoon: ERROR: phase1 negotiation failed due to send error. e596419712a16b74:0000000000000000
      Aug 25 10:00:30 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:31 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3.ip queued due to no phase1 found.
      Aug 25 10:00:31 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3.ip[500]
      Aug 25 10:00:31 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:32 colbert racoon: ERROR: phase1 negotiation failed due to send error. 52f97f80f9d35273:0000000000000000
      Aug 25 10:00:32 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:37 colbert racoon: INFO: IPsec-SA request for snapGear.ip queued due to no phase1 found.
      Aug 25 10:00:37 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>snapGear.ip[500]
      Aug 25 10:00:37 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:37 colbert racoon: ERROR: phase1 negotiation failed due to send error. 109a0bde22d78759:0000000000000000
      Aug 25 10:00:37 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:42 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3rc1.ip queued due to no phase1 found.
      Aug 25 10:00:42 colbert racoon: INFO: initiate new phase 1 negotiation: pfsense2.0.ip[500]<=>pfsense1.2.3rc1.ip[500]
      Aug 25 10:00:42 colbert racoon: INFO: begin Aggressive mode.
      Aug 25 10:00:42 colbert racoon: ERROR: phase1 negotiation failed due to send error. 48d8239318d9eac1:0000000000000000
      Aug 25 10:00:42 colbert racoon: ERROR: failed to begin ipsec sa negotication.
      Aug 25 10:00:45 colbert racoon: INFO: IPsec-SA request for pfsense1.2.3rc1.ip queued due to no phase1 found.

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

        I have switched all of my tunnels to main mode as suggested to me in #pfSense IRC as well as suggested on a similar thread (http://forum.pfsense.org/index.php/topic,34595.0.html).  I will report the success or failure, in a couple days.

        1 Reply Last reply Reply Quote 0
        • K
          kalu
          last edited by

          i had quite similar issue with ipsec and i switched to open vpn
          http://forum.pfsense.org/index.php/topic,39383.0.html
          may be a bug in ipsec in v2
          thanks

          i love pfsense because i love open source.

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

            Here is what I did, and I think it has resolved the issue:

            1.  Switched all tunnels to main mode.
            2.  Disabled DPD (Dead Peer Detection)

            So far all good.  *Knocking on wood.

            1 Reply Last reply Reply Quote 0
            • K
              kalu
              last edited by

              afinkinfotech thanks for the info
              i already had tried that when this problem first aroused.
              and doing that didn't helped me but for some it might work

              1. changed mode to main mode
              2. disabled DPD
              3. ticked prefer old IPSEC
                worked for 2-3 hours without any problem and raccon stops after that.
                tried to read the log but could not find the actual cause.
                friends at this forum suggested might be a mismatching configuration but that's not so because it works for hours.
                so what i diagnosed was IPSEC between pfsense to pfsense is perfect but there might be problem with other hardwares in my case it was Trendnet Router.
                thanks for sharing
                kalu

              i love pfsense because i love open source.

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

                It's quite possible that the DPD (Dead Peer Detection) feature is the culprit for some of the problems with IPsec VPNs to third-party routers reported here, since pfSense 2.0 uses the latest racoon (ipsec-tools 0.8.0).

                Have a look at the discussion and patch at ipsec-tools list:

                http://sourceforge.net/mailarchive/forum.php?thread_name=4DA4F48F.1060809%40open.ch&forum_name=ipsec-tools-devel

                Racoon (0.8.0) strictly checks the cookies within the encrypted part of
                DPD messages. According to RFC 3706 section 5.3 [1], the SPI content may
                contain the cookies, but it does not have to.

                In comparison, pluto from openswan strictly checks the SPI size,
                tolerating any SPI content. But the SPI size can be arbitrary as well,
                according to RFC.

                In the field I encountered a Cisco device (version/type unknown; Vendor
                ID: CISCO-UNITY), which sends the cookies of the encrypted part of DPD
                packets in reversed order, "violating" section 5.3 of RFC 3706 as I
                understand the relevant phrase:

                • Security Parameter Index (16 octets) - SHOULD be set to the
                    cookies of the Initiator and Responder of the IKE SA (in that
                    order)

                So my understanding is "you may put the cookies in there, and if you do,
                they must come in the given order".

                Since I fail to see any security implication, I produced this patch that
                makes racoon ignore the cookie content in DPD acks. This is in full
                compliance to RFC 3706 and allows racoon to use DPD with old Cisco
                devices that send inverted cookies (initiator/responder) in the
                encrypted part of the packets.

                This patch can also make DPD work with other vendors that do not send
                valid cookies within the DPD payload at all.

                Because the sequence number, which is in the encrypted part of DPD
                packets, is still being checked, this does not mean that racoon will
                accept bogus DPD acks.

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

                  Hello everyone,
                    Thank you for responses.  I have since downgraded to 1.2.3 stable and have not had a tunnel drop out since.  It is too bad because I really wanted to use some of the new functionality of pfSense 2.0 however, everyone is much happier now that the network is stable.

                  Andrew

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