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

    Upgrade to 2.2.4 –> The VPN Shared Secret is incorrect

    Scheduled Pinned Locked Moved IPsec
    18 Posts 4 Posters 9.0k 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.
    • D
      dgwilson
      last edited by

      Client is connecting to an IP Address.

      Always has. Hmmm, recommended config change somewhere? Interesting.

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

        Was curious if by FQDN, in case that made it not match ipsec.secrets for some reason.

        Try changing your IP in ipsec.secrets to:

        %any @dgw.kiwi : PSK ...

        Then run 'ipsec stop && ipsec start' and try to connect again. If you have other connections you don't want to drop, just a 'ipsec rereadall' will suffice, a stop/start just makes really sure everything previous is cleared out, and any SAs are deleted.

        If that doesn't work, try omitting the %any part in the above. If that doesn't work, take the leading part out entirely so you have something like:

         : PSK ...

        And let us know the results.

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

          I changed ipsec.secrets to:
          %any @dgw.kiwi : PSK 0<deleted>=
          203.97.236.202 dgwilson : PSK 0<deleted>=

          Initiated the stop and start… from the command line.
          Received the same error... Shared Secret is incorrect.

          I confirm that the contents of ipsec.secrets was correct before and after the connection.
          Stopping and starting the service via the GUI causes ipsec.secrets to be re-created. (I suspect you knew that. :-) )

          Aug 7 17:39:31 charon: 15[NET] <con2|1>sending packet: from 203.97.236.202[500] to 192.168.10.140[500] (432 bytes)
          Aug 7 17:39:31 charon: 15[IKE] <con2|1>sending retransmit 1 of response message ID 0, seq 1
          Aug 7 17:39:31 charon: 15[IKE] <con2|1>sending retransmit 1 of response message ID 0, seq 1
          Aug 7 17:39:27 charon: 15[IKE] <con2|1>INFORMATIONAL_V1 request with message ID 3403150820 processing failed
          Aug 7 17:39:27 charon: 15[IKE] <con2|1>INFORMATIONAL_V1 request with message ID 3403150820 processing failed
          Aug 7 17:39:27 charon: 15[IKE] <con2|1>ignore malformed INFORMATIONAL request
          Aug 7 17:39:27 charon: 15[IKE] <con2|1>ignore malformed INFORMATIONAL request
          Aug 7 17:39:27 charon: 15[IKE] <con2|1>message parsing failed
          Aug 7 17:39:27 charon: 15[IKE] <con2|1>message parsing failed
          Aug 7 17:39:27 charon: 15[ENC] <con2|1>could not decrypt payloads
          Aug 7 17:39:27 charon: 15[ENC] <con2|1>invalid HASH_V1 payload length, decryption failed?
          Aug 7 17:39:27 charon: 15[NET] <con2|1>received packet: from 192.168.10.140[4500] to 203.97.236.202[4500] (76 bytes)
          Aug 7 17:39:27 charon: 15[NET] <con2|1>sending packet: from 203.97.236.202[500] to 192.168.10.140[500] (432 bytes)
          Aug 7 17:39:27 charon: 15[ENC] <con2|1>generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V V ]
          Aug 7 17:39:27 charon: 15[CFG] <1> selected peer config "con2"
          Aug 7 17:39:27 charon: 15[CFG] <1> looking for XAuthInitPSK peer configs matching 203.97.236.202…192.168.10.140[dgw.kiwi]
          Aug 7 17:39:27 charon: 15[IKE] <1> 192.168.10.140 is initiating a Aggressive Mode IKE_SA
          Aug 7 17:39:27 charon: 15[IKE] <1> 192.168.10.140 is initiating a Aggressive Mode IKE_SA
          Aug 7 17:39:27 charon: 15[IKE] <1> received DPD vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received DPD vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received Cisco Unity vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received Cisco Unity vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received XAuth vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received XAuth vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
          Aug 7 17:39:27 charon: 15[IKE] <1> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID</con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></con2|1></deleted></deleted>

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

            I have continued… removing the %any
            ... that met with the same fate of Shared Secret is incorrect.

            and continuing again to remove the dgw.kiwi so that I'm left with : PSK...

            and... we have a connection! Success.

            I'm happy to continue the playing and experimenting to assist with the fault diagnosis.
            Let me know what you'd like me to do.

            • David
            1 Reply Last reply Reply Quote 0
            • J
              juniper80
              last edited by

              @dgwilson:

              and continuing again to remove the dgw.kiwi so that I'm left with : PSK…

              and... we have a connection! Success.

              I had the same issue (Update from 2.1 -> 2.2.4, IPsec Phase1 keeps failing)

              I can confirm, this worked for me as well….

              woohoo!

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

                @dgwilson:

                Stopping and starting the service via the GUI causes ipsec.secrets to be re-created. (I suspect you knew that. :-) )

                Yeah, I meant to run those commands from the shell, which won't regenerate the conf files.

                @dgwilson:

                and… we have a connection! Success.

                Ok good, thanks for that. I'll check into that further to see what the difference is.

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

                  @juniper80:

                  I had the same issue (Update from 2.1 -> 2.2.4, IPsec Phase1 keeps failing)

                  I can confirm, this worked for me as well….

                  With iOS and/or OS X mobile clients?

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

                    I have tested on iOS as well.

                    The connection failed until I repeated the edits required on ipsec.secrets by making it look like…

                    : PSK ...

                    • David
                    1 Reply Last reply Reply Quote 0
                    • C
                      cvance
                      last edited by

                      Issue and solution confirmed. Thanks for all the help.

                      1 Reply Last reply Reply Quote 0
                      • J
                        juniper80
                        last edited by

                        @cmb:

                        @juniper80:

                        I had the same issue (Update from 2.1 -> 2.2.4, IPsec Phase1 keeps failing)

                        I can confirm, this worked for me as well….

                        With iOS and/or OS X mobile clients?

                        For me this solved the issue on Windows with Shrewsoft VPN Client.

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