Upgrade to 2.2.4 –> The VPN Shared Secret is incorrect
-
You have the client connecting to an IP or hostname?
-
Client is connecting to an IP Address.
Always has. Hmmm, recommended config change somewhere? Interesting.
- David
-
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.
-
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> -
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
-
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!
-
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.
and… we have a connection! Success.
Ok good, thanks for that. I'll check into that further to see what the difference is.
-
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?
-
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
-
Issue and solution confirmed. Thanks for all the help.
-
@cmb:
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.