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.
    • C
      cmb
      last edited by

      You have the client connecting to an IP or hostname?

      1 Reply Last reply Reply Quote 0
      • 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.