Dear Andrew,
Thanks for the analysis and suggestion. Now I have these options
commented out in ipsec.conf:
# leftxauthserver=yes
# rightxauthclient=yes
# xauthby=file
And it is indeed making some more progress. I can see in the log that it
says "IKE SA established", and then libreswan proceeds to generating and
sending a ModeCfg, but then later it says in the log:
| received encrypted packet from 192.168.12.87:4500
| got payload 0x100 (ISAKMP_NEXT_HASH) needed: 0x100 opt: 0x0
| byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0xf7
but should have been zero (ignored)
"xauth-psk"[1] 192.168.12.87 #1: 9063-byte length of ISAKMP Hash
Payload is larger than can fit
"xauth-psk"[1] 192.168.12.87 #1: malformed payload in packet
| IKEv1 packet dropped
And this is what the android client app printed to logcat:
I FORTIKE : 2022-03-16 16:39:28.916 Adding remote and local NAT-D
payloads.
I FORTIKE : 2022-03-16 16:39:28.916 Hashing
<server.address.redacted>[4500] with algo #1 (NAT-T forced)
I FORTIKE : 2022-03-16 16:39:28.916 Hashing 192.168.12.87[4500] with
algo #1 (NAT-T forced)
I FORTIKE : 2022-03-16 16:39:28.916 Rekey life time: 28500
I FORTIKE : 2022-03-16 16:39:28.917 ISAKMP-SA established
192.168.12.87-<server.address.redacted>
spi:d2ef9e98883a5b6e:9521bbd1fdc60297
W FORTIKE : 2022-03-16 16:39:28.930 Short payload
W FORTIKE : 2022-03-16 16:39:29.425 Short payload
W FORTIKE : 2022-03-16 16:39:29.929 Short payload
W FORTIKE : 2022-03-16 16:39:30.932 Short payload
W FORTIKE : 2022-03-16 16:39:32.929 Short payload
W FORTIKE : 2022-03-16 16:39:36.936 Short payload
W FORTIKE : 2022-03-16 16:39:44.979 Short payload
I FortiClient VPN: Could not establish session on the IPsec daemon
I FORTIKE : 2022-03-16 16:39:53.994 FortiIKE daemon exiting...
I FortiClient VPN: Connection failed: Could not establish session on
the IPsec daemon
I'm not sure what is happening there. Is the client trying some sort of
phase-2 but somehow the libreswan setup is not expecting it?
Thanks.
Wolf
On 16/03/2022 07:25, Andrew Cagney wrote:
if ((req_policy ^ c->policy) & policy_exact_mask) continue
(PSK+AGGRESSIVE+IKEV1_ALLOW) ^
(PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO)
& (XAUTH+AGGRESSIVE+IKEV1_ALLOW)
If my math is right, this lacks XAUTH, which should have come from
preparse_isakmp_sa_body(sa_pd->pbs); is something missing in the
payload?
It looks like:
Mar 13 16:19:32.346676: | ******parse ISAKMP Oakley attribute:
Mar 13 16:19:32.346688: | af+type: AF+OAKLEY_AUTHENTICATION_METHOD (0x8003)
Mar 13 16:19:32.346699: | length/value: 1 (0x1)
which is:
enum ikev1_auth_method {
OAKLEY_PRESHARED_KEY = 1,
but to get XAUTH, I'm guessing it needs to see something like:
| ******parse ISAKMP Oakley attribute:
| af+type: AF+OAKLEY_AUTHENTICATION_METHOD (0x8003)
| length/value: 65001 (fd e9)
| [65001 is XAUTHInitPreShared]
https://testing.libreswan.org/v4.6-409-g0dd023c306-main/xauth-pluto-04/OUTPUT/east.pluto.log.gz
if the xauth parts of the config are dropped, does it get further?
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
