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

    Ipsec problem 2.1.5 >> 2.2 rc

    Scheduled Pinned Locked Moved 2.2 Snapshot Feedback and Problems - RETIRED
    23 Posts 5 Posters 10.6k 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.
    • E
      eri--
      last edited by

      Can you also upgrade to the latest snapshots and test again?

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

        I don't want to hijack this thread since I am not 100% we both have the same problem - but after updating to this morning's snapshot, I see no ultimate change in behaviour.

        1 Reply Last reply Reply Quote 0
        • O
          ondokuz
          last edited by

          I  am using last snapshot.
          best regards.

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

            This is a bug in racoon, can you try to enable NAT-T or disable it on 2.1.5?

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

              I think that might be the racoon bug I originally thought kitdavis' issue was (and that may have been the original issue there, but Ermal found the actual source issue today and is working on a fix right now). In that case, switching to main mode from aggressive on both sides should work around it.

              1 Reply Last reply Reply Quote 0
              • O
                ondokuz
                last edited by

                upgraded last snapshot
                last logs..

                website A : pfsense 2.2.RC
                website B pfsense 2.1.5

                When the server named pfsense 2.2Rc is restarted, the vpn is disconnected.
                Connection with website A can only be made when forced manually. Automatic connection can not be made.

                best regards

                SITE A LOGS

                Jan 8 13:49:37 charon: 15[IKE] <17> 88.88.88.50 is initiating a Aggressive Mode IKE_SA
                Jan 8 13:49:37 charon: 15[IKE] 88.88.88.50 is initiating a Aggressive Mode IKE_SA
                Jan 8 13:49:37 charon: 15[CFG] looking for pre-shared key peer configs matching 88.88.88.12…88.88.88.50[88.88.88.50]
                Jan 8 13:49:37 charon: 15[CFG] selected peer config "con5000"
                Jan 8 13:49:37 charon: 15[ENC] generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V V ]
                Jan 8 13:49:37 charon: 15[NET] sending packet: from 88.88.88.12[500] to 88.88.88.50[500] (432 bytes)
                Jan 8 13:49:41 charon: 15[IKE] <con5000|17>sending retransmit 1 of response message ID 0, seq 1
                Jan 8 13:49:41 charon: 15[IKE] sending retransmit 1 of response message ID 0, seq 1
                Jan 8 13:49:41 charon: 15[NET] sending packet: from 88.88.88.12[500] to 88.88.88.50[500] (432 bytes)
                Jan 8 13:49:45 charon: 15[KNL] unable to query SAD entry with SPI 0d9a6414: No such file or directory (2)
                Jan 8 13:49:47 charon: 15[NET] received packet: from 88.88.88.50[500] to 88.88.88.12[500] (372 bytes)
                Jan 8 13:49:47 charon: 15[IKE] <con5000|17>received retransmit of request with ID 0, retransmitting response
                Jan 8 13:49:47 charon: 15[IKE] received retransmit of request with ID 0, retransmitting response
                Jan 8 13:49:47 charon: 15[NET] sending packet: from 88.88.88.12[500] to 88.88.88.50[500] (432 bytes)
                Jan 8 13:49:48 charon: 15[IKE] <con5000|17>sending retransmit 2 of response message ID 0, seq 1
                Jan 8 13:49:48 charon: 15[IKE] sending retransmit 2 of response message ID 0, seq 1
                Jan 8 13:49:48 charon: 15[NET] sending packet: from 88.88.88.12[500] to 88.88.88.50[500] (432 bytes)
                Jan 8 13:49:57 charon: 15[NET] received packet: from 88.88.88.50[500] to 88.88.88.12[500] (372 bytes)
                Jan 8 13:49:57 charon: 15[IKE] <con5000|17>received retransmit of request with ID 0, retransmitting response
                Jan 8 13:49:57 charon: 15[IKE] received retransmit of request with ID 0, retransmitting response
                Jan 8 13:49:57 charon: 15[NET] sending packet: from 88.88.88.12[500] to 88.88.88.50[500] (432 bytes)
                Jan 8 13:50:01 charon: 15[IKE] <con5000|17>sending retransmit 3 of response message ID 0, seq 1
                Jan 8 13:50:01 charon: 15[IKE] sending retransmit 3 of response message ID 0, seq 1
                Jan 8 13:50:01 charon: 15[NET] sending packet: from 88.88.88.12[500] to 88.88.88.50[500] (432 bytes)
                Jan 8 13:50:02 charon: 15[KNL] unable to query SAD entry with SPI 0d9a6414: No such file or directory (2)
                Jan 8 13:50:07 charon: 09[JOB] deleting half open IKE_SA after timeout

                XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

                SITE B LOGS

                racoon: INFO: caught signal 15
                Jan 8 13:49:32 racoon: INFO: racoon process 90463 shutdown
                Jan 8 13:49:37 racoon: INFO: @(#)ipsec-tools 0.8.1 (http://ipsec-tools.sourceforge.net)
                Jan 8 13:49:37 racoon: INFO: @(#)This product linked OpenSSL 1.0.1i 6 Aug 2014 (http://www.openssl.org/)
                Jan 8 13:49:37 racoon: INFO: Reading configuration from "/var/etc/ipsec/racoon.conf"
                Jan 8 13:49:37 racoon: [Self]: INFO: 88.88.88.50[4500] used for NAT-T
                Jan 8 13:49:37 racoon: [Self]: INFO: 88.88.88.50[4500] used as isakmp port (fd=14)
                Jan 8 13:49:37 racoon: [Self]: INFO: 88.88.88.50[500] used for NAT-T
                Jan 8 13:49:37 racoon: [Self]: INFO: 88.88.88.50[500] used as isakmp port (fd=15)
                Jan 8 13:49:37 racoon: INFO: unsupported PF_KEY message REGISTER
                Jan 8 13:49:37 racoon: ERROR: such policy already exists. anyway replace it: 10.0.6.1/32[0] 10.0.6.0/24[0] proto=any dir=out
                Jan 8 13:49:37 racoon: ERROR: such policy already exists. anyway replace it: 10.0.6.0/24[0] 10.0.6.1/32[0] proto=any dir=in
                Jan 8 13:49:37 racoon: ERROR: such policy already exists. anyway replace it: 10.0.6.0/24[0] 10.0.20.0/24[0] proto=any dir=out
                Jan 8 13:49:37 racoon: ERROR: such policy already exists. anyway replace it: 10.0.20.0/24[0] 10.0.6.0/24[0] proto=any dir=in
                Jan 8 13:49:37 racoon: ERROR: such policy already exists. anyway replace it: 10.0.6.0/24[0] 10.0.1.0/24[0] proto=any dir=out
                Jan 8 13:49:37 racoon: ERROR: such policy already exists. anyway replace it: 10.0.1.0/24[0] 10.0.6.0/24[0] proto=any dir=in
                Jan 8 13:49:37 racoon: [sistem_odasi]: INFO: IPsec-SA request for 88.88.88.12 queued due to no phase1 found.
                Jan 8 13:49:37 racoon: [sistem_odasi]: INFO: initiate new phase 1 negotiation: 88.88.88.50[500]<=>88.88.88.12[500]
                Jan 8 13:49:37 racoon: INFO: begin Aggressive mode.
                Jan 8 13:49:37 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:49:41 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:49:47 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:49:48 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:49:57 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:50:01 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:50:07 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:50:08 racoon: [sistem_odasi]: [88.88.88.12] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP 88.88.88.12[0]->88.88.88.50[0]
                Jan 8 13:50:08 racoon: INFO: delete phase 2 handler.
                Jan 8 13:50:11 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:50:17 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:50:18 racoon: [sistem_odasi]: [88.88.88.12] ERROR: ignore the packet, received unexpecting payload type 20.
                Jan 8 13:50:21 racoon: [sistem_odasi]: [88.88.88.12] INFO: request for establishing IPsec-SA was queued due to no phase1 found.
                Jan 8 13:50:27 racoon: ERROR: phase1 negotiation failed due to time up. 35aa054d262e4cfc:0000000000000000
                Jan 8 13:50:52 racoon: [sistem_odasi]: [88.88.88.12] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP 88.88.88.12[0]->88.88.88.50[0]
                Jan 8 13:50:52 racoon: INFO: delete phase 2 handler.</con5000|17></con5000|17></con5000|17></con5000|17></con5000|17>

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

                  Do you have multiple phase2 on an IKEv1 tunnel?

                  Also try enabling NAT-T if possible on your 2.1.x side.

                  1 Reply Last reply Reply Quote 0
                  • O
                    ondokuz
                    last edited by

                    Do you have multiple phase2 on an IKEv1 tunnel?

                    No. only one .

                    Also try enabling NAT-T if possible on your 2.1.x side.

                    enable.

                    Negotiation mode : Aggressive to main >>>> running.. problem?

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

                      @ondokuz:

                      Negotiation mode : Aggressive to main >>>> running.. problem?

                      You saying changing from aggressive to main fixed it?

                      1 Reply Last reply Reply Quote 0
                      • O
                        ondokuz
                        last edited by

                        yes. main mod fixed

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

                          Ok good, thanks for the confirmation. Yeah then that was the racoon bug we were thinking it was.

                          1 Reply Last reply Reply Quote 0
                          • O
                            ondokuz
                            last edited by

                            2.2-RC (amd64)
                            built on Fri Jan 09 09:55:04 CST 2015
                            FreeBSD 10.1-RELEASE-p3

                            Aggressive mod dont connect… problem don't solve..

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

                              Yes that's a problem in racoon, e.g. the 2.1.x side. In that circumstance, you won't be able to use aggressive mode (at least until you upgrade the other end to 2.2). Main is preferable anyway.

                              1 Reply Last reply Reply Quote 0
                              • O
                                ondokuz
                                last edited by

                                thank you very much.  Which do you recommend ?  Which is more secure? aggressive or main ?
                                best regards.

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

                                  Main is always best unless it's not an option for some reason (like in some mobile IPsec scenarios). For site to site VPNs, you should always use main mode, unless you're connecting to some odd third party device that doesn't support it.

                                  1 Reply Last reply Reply Quote 0
                                  • T
                                    tracer
                                    last edited by

                                    Hi,
                                    I can't get my tunnels connected anymore since build from 7th of Jan.
                                    before it was working good with Aggressive Mode, but even switching to Main mode didn't help.
                                    I have 2 phase 2 policies.
                                    The other side of course is a pfsense 2.1.5
                                    I'm using Main, AES/256, with SHA, DH Key2 with NAT-T enabled.
                                    Phase2: ESP, AES(auto) with SHA1, MD5, PFS key2

                                    Updated to build 10th of Jan.

                                    Errors on the 2.1.5:

                                    
                                    Jan 10 17:17:16 	racoon: ERROR: phase1 negotiation failed due to time up. 14607675c166a280:0000000000000000
                                    Jan 10 17:17:10 	racoon: [mchome kabel]: [9.1.176.100] INFO: request for establishing IPsec-SA was queued due to no phase1 found.
                                    Jan 10 17:17:07 	racoon: [mchome kabel]: [9.1.176.100] INFO: request for establishing IPsec-SA was queued due to no phase1 found.
                                    Jan 10 17:17:02 	racoon: INFO: delete phase 2 handler.
                                    Jan 10 17:17:02 	racoon: [mchome kabel]: [9.1.176.100] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP 9.1.176.100[0]->6.1.47.71[0]
                                    
                                    

                                    You phase1 does not match.
                                    Your ips might have changed?

                                    1 Reply Last reply Reply Quote 0
                                    • O
                                      ondokuz
                                      last edited by

                                      my pfsense 2.2 configuration.

                                      working all snapshots….


                                      my pfsense 2.1.5 configuration


                                      1 Reply Last reply Reply Quote 0
                                      • T
                                        tracer
                                        last edited by

                                        This is pretty much my config, except that i have Phase 2 MD5 enabled as well.
                                        And DPD is disabled right now, but was enabled before, with no success.

                                        1 Reply Last reply Reply Quote 0
                                        • O
                                          ondokuz
                                          last edited by

                                          Can you do the same with me the configure.. my screenshots..

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

                                            @tracer:

                                            This is pretty much my config, except that i have Phase 2 MD5 enabled as well.
                                            And DPD is disabled right now, but was enabled before, with no success.

                                            Make sure you're on the latest snapshot, some things were in flux with IPsec this past week which could affect what you're doing. If it's still an issue on the latest snapshot, please start a new thread on this board, as that's a separate issue from OP's.

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