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

    Another IPSEC issue

    2.2 Snapshot Feedback and Problems - RETIRED
    4
    17
    30.2k
    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.
    • C
      cmb
      last edited by

      Have you upgraded to the latest available? Some this this past week were in flux in IPsec, you'll want to be on the latest available snapshot.

      If you already are, or upgrade and it continues, could you open that back up where I can reach it?

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

        As long as I keep updating to the newest snapshoot each day, the problem never occurs - (in this case, I stayed on Friday's snapshot and the problem started on Sunday.    I will upgrade to the newest snapshot this morning and then leave that in place and notify you when/if the tunnels are lost.

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by

          This might be related to rekey requirments even being disabled or some mismatch with the other side.

          Can you see if the rekey times shown on the status->ipsec are approximately 24 hours.

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

            Reuath is shown as being 7 hours.

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by 

              
Jan 11 22:38:46   charon: 04[IKE] <14428> no IKE config found for 69.69.69.83...142.142.142.142, sending NO_PROPOSAL_CHOSEN

              Looking at this again, do you have anything special in your configuration? Dyndns?
              Also does it try to do re-authentication with agressive mode? If yes, does strongswan log anything more useful there?
              Normally you should increase the IKE log level to detect this.

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

                No, everything is pretty simple - the wild card is there are 18 tunnels, and a rather unstable connection (fixed wireless) so connectivity is often lost several times during the day.

                Chris changed the debug levels (I think) when we were working on the other IPSEC problem.  Both IKE and IKE Child were set to Diag - I moved the log level to Highest. All of the tunnels were originally set to use aggressive mode but I have moved most of them to main over the last few days and should have the rest migrated today.  The "broken" tunnels this morning were a mix of aggressive and main.  I upgraded to the latest snapshot earlier today, so I expect the problem will occur some time late tomorrow.

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

                  This happened today to me as well. Seems specific to IKEv1, but doesn't appear to be universal to all IKEv1. Have you noticed anything common to the ones that are doing that for you vs. the ones that aren't? Or do the affected ones change in your case?

                  I dropped my P1 lifetime down to an hour in hopes of being able to replicate it more quickly. Seems to coincide with rekeying of P1, at least if I remember your configs. You have a P1 lifetime of 86400 on the affected connections, and something less than that as the P2 lifetime?

                  I was thinking it was something new given it's never happened to me before nor do I seem to find it from anyone else, but the symptoms might match what you'd posted in December. The fact at the time it was only higher numbered connections doing it, I figured it was part of the other overall issue we'd fixed with the identifiers there that fixed the general problem you had. Is it still the higher ID ones that have an issue?

                  1 Reply Last reply Reply Quote 0
                  • E
                    eri--
                    last edited by

                    Can you please put this systcl under system->advanced->tunables
                    net.inet.ipsec.debug = 0xffffff

                    After that tell me when the issue happens if you see anything on the output of dmesg -a or paste the last lines from it here.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eri--
                      last edited by

                      Also can you please give me the output of
                      netstat -f inet -sp esp

                      when you have the issue?

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

                        We backed down to strongswan 5.2.1 to see if that fixes this issue. I upgraded your system kitdavis and am keeping an eye on its logs. Earlier today, it started exhibiting the same symptoms about 12 hours after the upgrade. So we should know one way or another within the next 12 hours or so.

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

                          I have a similar issue as described here, and it it still seems to be the case on latest snapshot (2.2-RC (amd64) built on Fri Jan 16 11:53:08 CST 2015 FreeBSD 10.1-RELEASE-p4 on PC-Engines APU Board).

                          2 IPSEC Tunnels with respectively 2 and 4 phase 2 entries.  And after a few hours, some of the phases 2 are not reachable anymore, while the others are still there. For example users connected to the LAN cannot connect to the tunneled IP's while users connected via OpenVPN to our network still can.

                          Stopping and restarting the IPSEC service "fixes" the issue (clicking on the Restart IPSEC icon doesn't).

                          I could not reproduce it yet, but the logfile says approximately this around the time of a disconnect:

                          
Jan 19 15:43:16 pf charon: 02[ENC] generating INFORMATIONAL_V1 request 3956259368 [ HASH N(DPD) ]
Jan 19 15:43:16 pf charon: 02[NET] sending packet: from ip1[500] to ip2[500] (92 bytes)
Jan 19 15:43:16 pf charon: 02[NET] received packet: from ip2[500] to ip1[500] (92 bytes)
Jan 19 15:43:16 pf charon: 02[ENC] parsed INFORMATIONAL_V1 request 735452451 [ HASH N(DPD_ACK) ]
Jan 19 15:43:20 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (364 bytes)
Jan 19 15:43:20 pf charon: 02[ENC] parsed QUICK_MODE request 141741184 [ HASH SA No KE ID ID ]
Jan 19 15:43:20 pf charon: 02[ENC] received HASH payload does not match
Jan 19 15:43:20 pf charon: 02[IKE] <con2000|13>integrity check failed
Jan 19 15:43:20 pf charon: 02[IKE] integrity check failed
Jan 19 15:43:20 pf charon: 02[ENC] generating INFORMATIONAL_V1 request 1348227468 [ HASH N(INVAL_HASH) ]
Jan 19 15:43:20 pf charon: 02[NET] sending packet: from ip1[500] to ip3[500] (76 bytes)
Jan 19 15:43:20 pf charon: 02[IKE] <con2000|13>QUICK_MODE request with message ID 141741184 processing failed
Jan 19 15:43:20 pf charon: 02[IKE] QUICK_MODE request with message ID 141741184 processing failed
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13>sending DPD request
Jan 19 15:43:21 pf charon: 02[IKE] sending DPD request
Jan 19 15:43:21 pf charon: 02[ENC] generating INFORMATIONAL_V1 request 3461990251 [ HASH N(DPD) ]
Jan 19 15:43:21 pf charon: 02[NET] sending packet: from ip1[500] to ip3[500] (92 bytes)
Jan 19 15:43:21 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (92 bytes)
Jan 19 15:43:21 pf charon: 02[ENC] parsed INFORMATIONAL_V1 request 3939011389 [ HASH N(DPD_ACK) ]
Jan 19 15:43:21 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (364 bytes)
Jan 19 15:43:21 pf charon: 02[ENC] parsed QUICK_MODE request 3030064237 [ HASH SA No KE ID ID ]
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13>detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:21 pf charon: 02[IKE] detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:21 pf charon: 02[ENC] generating QUICK_MODE response 3030064237 [ HASH SA No KE ID ID ]
Jan 19 15:43:21 pf charon: 02[NET] sending packet: from ip1[500] to ip3[500] (380 bytes)
Jan 19 15:43:21 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (76 bytes)
Jan 19 15:43:21 pf charon: 02[ENC] parsed INFORMATIONAL_V1 request 2447641578 [ HASH N(INVAL_ID) ]
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13>received INVALID_ID_INFORMATION error notify
Jan 19 15:43:21 pf charon: 02[IKE] received INVALID_ID_INFORMATION error notify
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13>received INVALID_ID_INFORMATION error notify
Jan 19 15:43:21 pf charon: 02[IKE] received INVALID_ID_INFORMATION error notify
Jan 19 15:43:26 pf charon: 16[NET] received packet: from ip3[500] to ip1[500] (364 bytes)
Jan 19 15:43:26 pf charon: 16[ENC] parsed QUICK_MODE request 84872551 [ HASH SA No KE ID ID ]
Jan 19 15:43:26 pf charon: 16[IKE] <con2000|13>detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:26 pf charon: 16[IKE] detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:26 pf charon: 16[ENC] generating QUICK_MODE response 84872551 [ HASH SA No KE ID ID ]
Jan 19 15:43:26 pf charon: 16[NET] sending packet: from ip1[500] to ip3[500] (380 bytes)
Jan 19 15:43:26 pf charon: 16[NET] received packet: from ip3[500] to ip1[500] (76 bytes)
Jan 19 15:43:26 pf charon: 16[ENC] parsed INFORMATIONAL_V1 request 4148709878 [ HASH N(INVAL_ID) ]
Jan 19 15:43:26 pf charon: 16[IKE] <con2000|13>received INVALID_ID_INFORMATION error notify
Jan 19 15:43:26 pf charon: 16[IKE] received INVALID_ID_INFORMATION error notify
Jan 19 15:43:26 pf charon: 16[IKE] <con2000|13>received INVALID_ID_INFORMATION error notify</con2000|13></con2000|13></con2000|13></con2000|13></con2000|13></con2000|13></con2000|13></con2000|13></con2000|13>

                          To be continued !  I will try to tune the rekey/reauth settings later this week.  But with pfSense 2.1.x everything was very stable, so it seems quite 2.2-related to me.

                          1 Reply Last reply Reply Quote 0
                          • E
                            eri--
                            last edited by

                            What is the other side of the tunnel?

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

                              Hi Ermal and thanks for your answer :

                              @ermal:

                              What is the other side of the tunnel?

                              Not a pfsense for sure, but I will need to ask (in both case these are large companies with expensive setups).  Regards.

                              1 Reply Last reply Reply Quote 0
                              • E
                                eri--
                                last edited by

                                Which DH group you using?

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

                                  @swix:

                                  I have a similar issue as described here, and it it still seems to be the case on latest snapshot (2.2-RC (amd64) built on Fri Jan 16 11:53:08 CST 2015 FreeBSD 10.1-RELEASE-p4 on PC-Engines APU Board).

                                  Is your Internet connectivity extremely unstable? It appears that's the bulk of OP's issue, he's in the middle of nowhere with connectivity that's hit and miss and that seems to be the source of remaining issues there.

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

                                    IKE: AES 256 encryption with SHA1 auth, 7800 SA lifetime, IKE DH group : Group 5, MODP 1536
                                    IPSEC:  AES 256 encryption with SHA1 auth, 3600 SA lifetime, IPsec PFS group: Group 5, MODP 1536

                                    Line is very stable (DSL 30Mbit) and has not changed since the upgrade from pfsense 2.1.x to latest 2.2-RC.

                                    Everything remained quite stable the last 2-3 days, with only an issue this afternoon, which disappeared as usual after a complete stop + start of the ipsec service.

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post