[strongSwan] PSK Failing
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Sun Mar 25 01:18:18 CET 2018
Probably the wrong id and wrong rightsubnet. Just leave it as-is from the UsableExamples page and fill in the information (prune the stuff that you don't need, of course).
If you really need to know, you need to check the logs on the client, because it evidently doesn't answer to the last message that was sent.
On 25.03.2018 00:38, Ubaidul Khan wrote:
> Thank you Noel! I made some progress, but the Mac client is still not connecting. Here is the log file on the StrongSwan server:
>
> Mar 24 18:34:06 alpha charon: 08[NET] received packet: from 192.168.5.69[500] to 192.168.5.11[500] (788 bytes)
> Mar 24 18:34:06 alpha charon: 08[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V ]
> Mar 24 18:34:06 alpha charon: 08[IKE] received NAT-T (RFC 3947) vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received FRAGMENTATION vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] received DPD vendor ID
> Mar 24 18:34:06 alpha charon: 08[IKE] 192.168.5.69 is initiating a Main Mode IKE_SA
> Mar 24 18:34:06 alpha charon: 08[ENC] generating ID_PROT response 0 [ SA V V V V ]
> Mar 24 18:34:06 alpha charon: 08[NET] sending packet: from 192.168.5.11[500] to 192.168.5.69[500] (160 bytes)
> Mar 24 18:34:06 alpha charon: 09[NET] received packet: from 192.168.5.69[500] to 192.168.5.11[500] (228 bytes)
> Mar 24 18:34:06 alpha charon: 09[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
> Mar 24 18:34:06 alpha charon: 09[IKE] remote host is behind NAT
> Mar 24 18:34:06 alpha charon: 09[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
> Mar 24 18:34:06 alpha charon: 09[NET] sending packet: from 192.168.5.11[500] to 192.168.5.69[500] (244 bytes)
> Mar 24 18:34:06 alpha charon: 10[NET] received packet: from 192.168.5.69[4500] to 192.168.5.11[4500] (108 bytes)
> Mar 24 18:34:06 alpha charon: 10[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
> Mar 24 18:34:06 alpha charon: 10[CFG] looking for pre-shared key peer configs matching 192.168.5.11...192.168.5.69[192.168.1.8]
> Mar 24 18:34:06 alpha charon: 10[CFG] selected peer config "L2TP"
> Mar 24 18:34:06 alpha charon: 10[IKE] IKE_SA L2TP[1] established between 192.168.5.11[CN=acme.com <http://acme.com>, C=US, O=Acme Technologies Inc, OU=Network Technologies]...192.168.5.69[192.168.1.8]
> Mar 24 18:34:06 alpha charon: 10[IKE] scheduling reauthentication in 2670s
> Mar 24 18:34:06 alpha charon: 10[IKE] maximum IKE_SA lifetime 3210s
> Mar 24 18:34:06 alpha charon: 10[ENC] generating ID_PROT response 0 [ ID HASH ]
> Mar 24 18:34:06 alpha charon: 10[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (172 bytes)
> Mar 24 18:34:10 alpha charon: 12[NET] received packet: from 192.168.5.69[4500] to 192.168.5.11[4500] (108 bytes)
> Mar 24 18:34:10 alpha charon: 12[IKE] received retransmit of request with ID 0, retransmitting response
> Mar 24 18:34:10 alpha charon: 12[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (172 bytes)
> Mar 24 18:34:13 alpha charon: 13[NET] received packet: from 192.168.5.69[4500] to 192.168.5.11[4500] (108 bytes)
> Mar 24 18:34:13 alpha charon: 13[IKE] received retransmit of request with ID 0, retransmitting response
> Mar 24 18:34:13 alpha charon: 13[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (172 bytes)
> Mar 24 18:34:16 alpha charon: 14[NET] received packet: from 192.168.5.69[4500] to 192.168.5.11[4500] (108 bytes)
> Mar 24 18:34:16 alpha charon: 14[IKE] received retransmit of request with ID 0, retransmitting response
> Mar 24 18:34:16 alpha charon: 14[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (172 bytes)
> Mar 24 18:34:28 alpha charon: 15[NET] received packet: from 192.168.5.69[4500] to 192.168.5.11[4500] (108 bytes)
> Mar 24 18:34:28 alpha charon: 15[IKE] received retransmit of request with ID 0, retransmitting response
> Mar 24 18:34:28 alpha charon: 15[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (172 bytes)
> Mar 24 18:34:36 alpha charon: 16[IKE] sending DPD request
> Mar 24 18:34:36 alpha charon: 16[ENC] generating INFORMATIONAL_V1 request 3738696413 [ HASH N(DPD) ]
> Mar 24 18:34:36 alpha charon: 16[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (92 bytes)
> Mar 24 18:35:06 alpha charon: 03[IKE] sending DPD request
> Mar 24 18:35:06 alpha charon: 03[ENC] generating INFORMATIONAL_V1 request 3017683089 [ HASH N(DPD) ]
> Mar 24 18:35:06 alpha charon: 03[NET] sending packet: from 192.168.5.11[4500] to 192.168.5.69[4500] (92 bytes)
>
>
> Looks like the Security Association is successful on the server, but the Mac quits with the same error as before:
>
> "The L2TP-VPN Server did not respond. Try reconnecting. If the problem continues, verify
> settings and contact your Administrator."
>
>
>
> There is nothing in the Mac logs either. I did change the ipsec.conf on the server:
>
>
> config setup
> cachecrls=yes
> uniqueids=yes
> charondebug=""
>
> conn %default
> keyingtries=%forever
> dpddelay=30s
> dpdtimeout=120s
> authby=secret
> keyexchange=ikev2
>
>
>
> conn L2TP
> #aggressive=yes
> fragmentation=yes
> dpdaction=clear
> #Server IP
> left=192.168.5.11
> #Server default gateway
> # leftnexthop=192.168.5.254
> leftprotoport=17/1701
> rightprotoport=17/%any
> right=%any
> rightsubnet=0.0.0.0/0 <http://0.0.0.0/0>
> authby=secret
> # leftauth=psk
> # leftauth2=xauth
> # rightauth=psk
> # leftid="<insert-the-public-ip-here>"
>
> leftid="CN=access.acme.com <http://access.acme.com>, C=US, O="Acme Technologies Inc""
> leftcert=/etc/ipsec.d/certs/alpha_SSWAN_vpnHost_signed_cert.crt
>
>
> ikelifetime=1h
> keylife=8h
> ike=aes128-sha1-modp1536,aes128-sha1-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha1-modp1536,3des-sha1-modp1024,3des-md5-modp1536,3des-md5-modp1024
> esp=aes128-sha1-modp1536,aes128-sha1-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha1-modp1536,3des-sha1-modp1024,3des-md5-modp1536,3des-md5-modp1024
> auto=add
> keyexchange=ike
> type=transport
>
> What am I missing? Kindly share your thoughts.
>
> Thanks
>
> On Sat, Mar 24, 2018 at 1:17 PM, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting>> wrote:
>
> Please always address the mailing list, too.
>
> Then a little bit more text for you, so you can see your error.
>
> > Mar 24 09:41:06 alpha charon: 07[IKE] 192.168.5.69 is initiating a Main Mode IKE_SA
> > Mar 24 09:41:06 alpha charon: 09[IKE] found 1 matching config, but none allows pre-shared key authentication using Main Mode
>
> > conn L2TP
> > aggressive=yes
>
>
> I hope it's clear now.
>
> Btw, all those other conns are useless. They don't do anything.
>
> On 24.03.2018 16 <tel:24.03.2018%2016>:53, Ubaidul Khan wrote:
> > Thanks for replying, but none(of the two messages you sent) has any content.
> >
> > On Sat, Mar 24, 2018 at 11:02 AM, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze%2Bstrongswan-users-ml at thermi.consulting>>> wrote:
> >
> >
> >
> > On 24.03.2018 15 <tel:24.03.2018%2015> <tel:24.03.2018%2015>:02, Ubaidul Khan wrote:
> > > Mar 24 09:41:06 alpha charon: 09[IKE] found 1 matching config, but none allows pre-shared key authentication using Main Mode
> >
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180325/1ea3cc53/attachment-0001.sig>
More information about the Users
mailing list