<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Paul,<br>
<br>
I got the following to connect:<br>
conn test<br>
type=tunnel<br>
authby=secret<br>
auto=ignore<br>
left=82.19.158.192<br>
leftsourceip=172.17.2.1<br>
leftsubnet=172.17.2.0/24<br>
leftid=@nick<br>
right=%any<br>
rightid=@samsung<br>
salifetime=1h<br>
ikelifetime=8h<br>
ikev2=insist<br>
dpdaction=clear<br>
dpdtimeout=120<br>
dpddelay=30<br>
rekey=no<br>
#ike=aes128-sha2_256;modp1536<br>
#phase2alg=aes128-sha2_384<br>
#ike=aes256-sha2_256;modp2048<br>
#phase2alg=aes256-sha2_256<br>
sha2-truncbug=yes<br>
ike=aes256-sha2_512;modp2048,aes256-sha2_512;modp2048,aes128-sha2_512;modp2048,aes256-sha1;modp1024,aes128-sha1;modp1024<br>
esp=aes256-sha2_512,aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512<br>
rightaddresspool=172.17.4.16-172.17.4.31<br>
modecfgdns1=172.17.2.1<br>
leftxauthserver=yes<br>
rightxauthclient=yes<br>
leftmodecfgserver=yes<br>
rightmodecfgclient=yes<br>
modecfgpull=yes<br>
<br>
I needed some or all of the lines after the esp line. With this I
had a connection but no traffic passed.<br>
<br>
In Android I then went into the advanced options and set the remote
network to 172.17.2.0/24 and I could access the server on 172.17.2.1
but I could not ping anything on the LAN. OpenVPN can as can IPsec
traffic from a remote router LAN-LAN VPN. Is this an Android bug or
is there another issue? I saw another thread recently when someone
also had problems routing traffic.<br>
<br>
Regards,<br>
<br>
Nick<br>
<br>
<div class="moz-cite-prefix">On 28/04/2017 19:43, Nick Howitt wrote:<br>
</div>
<blockquote
cite="mid:5716f883-083d-73f5-d871-875046f74a2a@howitts.co.uk"
type="cite">
<br>
OK, I've tried a simpler PSK for the moment and I get past that
bit.
<br>
<br>
Now I get a no proposal chosen and I can't find a way out. Leaving
them empty does not work and I can't find a combination which
does:
<br>
<br>
This is with:
<br>
ike=aes256-sha2_256;modp2048
<br>
phase2alg=aes_gcm256-null,aes256-sha2_512,aes256-sha2_256
<br>
sha2-truncbug=yes
<br>
<br>
Apr 28 19:36:38 server pluto[2040]: packet from
85.255.235.101:48789: test IKE proposals for initial responder:
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048<br>
Apr 28 19:36:38 server pluto[2040]: packet from
85.255.235.101:48789: proposal
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
chosen from:
1:IKE:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[first-match]
2:IKE:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536
<br>
Apr 28 19:36:38 server pluto[2040]: packet from
85.255.235.101:48789: initiator guessed wrong keying material
group (DH24); responding with INVALID_KE_PAYLOAD requesting
MODP2048
<br>
Apr 28 19:36:38 server pluto[2040]: packet from
85.255.235.101:48789: sending unencrypted notification
v2N_INVALID_KE_PAYLOAD to 85.255.235.101:48789
<br>
Apr 28 19:36:38 server pluto[2040]: packet from
85.255.235.101:48789: proposal
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
chosen from:
1:IKE:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[first-match]
2:IKE:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536
<br>
Apr 28 19:36:38 server pluto[2040]: "test"[1] 85.255.235.101 #9:
STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2
cipher=aes_256 integ=sha256_128 prf=sha2_256 group=MODP2048}
<br>
Apr 28 19:36:38 server pluto[2040]: "test"[1] 85.255.235.101 #9:
new NAT mapping for #9, was 85.255.235.101:48789, now
85.255.235.101:10974
<br>
Apr 28 19:36:38 server pluto[2040]: "test"[1] 85.255.235.101 #9:
IKEv2 mode peer ID is ID_FQDN: '@nick'
<br>
Apr 28 19:36:38 server pluto[2040]: | ikev2_parent_inI2outR2_tail
returned STF_FAIL with v2N_NO_PROPOSAL_CHOSEN
<br>
Apr 28 19:36:38 server pluto[2040]: "test"[1] 85.255.235.101 #9:
sending unencrypted notification v2N_NO_PROPOSAL_CHOSEN to
85.255.235.101:10974
<br>
Apr 28 19:36:39 server pluto[2040]: packet from
85.255.235.101:10974: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:10974
<br>
Apr 28 19:36:41 server pluto[2040]: packet from
85.255.235.101:10974: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:10974
<br>
Apr 28 19:36:44 server pluto[2040]: packet from
85.255.235.101:10974: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:10974
<br>
<br>
sha2-truncbug makes no difference. It looks like it chooses a
proposal but then says it does not.
<br>
<br>
Regards,
<br>
<br>
Nick
<br>
<br>
On 28/04/2017 18:23, Nick Howitt wrote:
<br>
<blockquote type="cite">Thanks. I guessed that but I copied and
pasted them so I am not sure why. I'll try again.
<br>
<br>
Regards,
<br>
<br>
Nick
<br>
<br>
On 28/04/2017 18:09, Paul Wouters wrote:
<br>
<blockquote type="cite">It means your PSK's don't match.
<br>
<br>
Sent from my iPhone
<br>
<br>
<blockquote type="cite">On Apr 28, 2017, at 13:06, Nick
Howitt<a class="moz-txt-link-rfc2396E" href="mailto:nick@howitts.co.uk"><nick@howitts.co.uk></a> wrote:
<br>
<br>
Hi Paul,
<br>
<br>
I've trying to set up a very basic IKEv2+PSK conn from
Android 5.0.1 to libreswan 3.20 but it is giving errors:
<br>
<br>
conn test
<br>
type=tunnel
<br>
authby=secret
<br>
auto=add
<br>
left=82.19.158.192
<br>
leftsourceip=172.17.2.1
<br>
leftsubnet=172.17.2.0/24
<br>
right=%any
<br>
rightid=@nick
<br>
salifetime=1h
<br>
ikelifetime=8h
<br>
ikev2=insist
<br>
dpdaction=clear
<br>
dpdtimeout=120
<br>
dpddelay=30
<br>
rekey=no
<br>
<br>
and:
<br>
<br>
Apr 28 17:58:13 server pluto[3953]: packet from
85.255.235.101:36533: test IKE proposals for initial
responder:
1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192
2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192
3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536
4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536
(default)
<br>
Apr 28 17:58:13 server pluto[3953]: packet from
85.255.235.101:36533: proposal
2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;DH=MODP2048
chosen from:
1:IKE:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[first-match]
2:IKE:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[better-match]
<br>
Apr 28 17:58:13 server pluto[3953]: packet from
85.255.235.101:36533: initiator guessed wrong keying
material group (DH24); responding with INVALID_KE_PAYLOAD
requesting MODP2048
<br>
Apr 28 17:58:13 server pluto[3953]: packet from
85.255.235.101:36533: sending unencrypted notification
v2N_INVALID_KE_PAYLOAD to 85.255.235.101:36533
<br>
Apr 28 17:58:14 server pluto[3953]: packet from
85.255.235.101:36533: proposal
2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;DH=MODP2048
chosen from:
1:IKE:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[first-match]
2:IKE:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_256;PRF=HMAC_SHA1;DH=DH24;DH=ECP_384;DH=ECP_256;DH=MODP2048;DH=MODP1536[better-match]
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2
cipher=aes_gcm_16_256 integ=n/a prf=sha2_512 group=MODP2048}
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: new NAT mapping for #455, was 85.255.235.101:36533,
now 85.255.235.101:54219
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: IKEv2 mode peer ID is ID_FQDN: '@nick'
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: AUTH mismatch: Received AUTH != computed AUTH
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: PSK Authentication failed: AUTH mismatch!
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: sending unencrypted notification
v2N_AUTHENTICATION_FAILED to 85.255.235.101:54219
<br>
Apr 28 17:58:14 server pluto[3953]: |
ikev2_parent_inI2outR2_tail returned STF_FATAL
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4] 85.255.235.101
#455: deleting state (STATE_PARENT_R1)
<br>
Apr 28 17:58:14 server pluto[3953]: "test"[4]
85.255.235.101: deleting connection "test"[4] 85.255.235.101
instance with peer 85.255.235.101 {isakmp=#0/ipsec=#0}
<br>
Apr 28 17:58:15 server pluto[3953]: packet from
85.255.235.101:54219: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:54219
<br>
Apr 28 17:58:17 server pluto[3953]: packet from
85.255.235.101:54219: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:54219
<br>
Apr 28 17:58:20 server pluto[3953]: packet from
85.255.235.101:54219: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:54219
<br>
Apr 28 17:58:27 server pluto[3953]: packet from
85.255.235.101:54219: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:54219
<br>
Apr 28 17:58:37 server pluto[3953]: packet from
85.255.235.101:54219: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:54219
<br>
Apr 28 17:58:56 server pluto[3953]: packet from
85.255.235.101:54219: sending unencrypted notification
v2N_INVALID_IKE_SPI to 85.255.235.101:54219
<br>
<br>
It looks like it has agreed a proposal but I've no idea
about the AUTH mismatch. I know I have not configured an
addresspool. Is it necessary and causing this issue or is
there something else going on?
<br>
<br>
Regards,
<br>
<br>
Nick
<br>
_______________________________________________
<br>
Swan mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Swan@lists.libreswan.org">Swan@lists.libreswan.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a>
<br>
</blockquote>
</blockquote>
<br>
<br>
<br>
_______________________________________________
<br>
Swan mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Swan@lists.libreswan.org">Swan@lists.libreswan.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Swan mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Swan@lists.libreswan.org">Swan@lists.libreswan.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a>
<br>
</blockquote>
<br>
</body>
</html>