<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="monospace">In case it'd be useful, here's a much longer
snippet of the libreswan log file. After complaining about
malformed payload, it then goes into re-transmitting the ModeCfg 8
times:<br>
</font>
<blockquote><font face="monospace">| pstats #1 ikev1.isakmp
established<br>
"xauth-psk"[1] 192.168.12.87 #1: IKE SA established
{auth=PRESHARED_KEY cipher=3DES_CBC_192 integ=HMAC_MD5
group=MODP1536}<br>
| DPD: dpd_init() called on ISAKMP SA<br>
| DPD: Peer supports Dead Peer Detection<br>
| modecfg pull: quirk-poll policy:push not-client<br>
| parent state #1: AGGR_R2(established IKE SA) =>
MODE_CFG_R1(established IKE SA)<br>
"xauth-psk"[1] 192.168.12.87 #1: Sending MODE CONFIG set<br>
| opening output PBS ModecfgR1<br>
| **emit ISAKMP Message:<br>
| initiator SPI: 69 8b 70 ee 12 04 ce 2c<br>
| responder SPI: 60 9a f2 9c 09 af c4 11<br>
| next payload type: ISAKMP_NEXT_NONE (0x0)<br>
| ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)<br>
| exchange type: ISAKMP_XCHG_MODE_CFG (0x6)<br>
| flags: ISAKMP_FLAG_v1_ENCRYPTION (0x1)<br>
| Message ID: 3406270730 (cb 07 91 0a)<br>
| next payload chain: saving message location 'ISAKMP
Message'.'next payload type'<br>
| ***emit ISAKMP Hash Payload:<br>
| next payload type: ISAKMP_NEXT_NONE (0x0)<br>
| next payload chain: setting previous 'ISAKMP Message'.'next
payload type' to current ISAKMP Hash Payload
(8:ISAKMP_NEXT_HASH)<br>
| next payload chain: saving location 'ISAKMP Hash
Payload'.'next payload type' in 'ModecfgR1'<br>
| emitting 16 zero bytes of HASH DATA into ISAKMP Hash Payload<br>
| emitting length of ISAKMP Hash Payload: 20<br>
| ***emit ISAKMP Mode Attribute:<br>
| next payload type: ISAKMP_NEXT_NONE (0x0)<br>
| Attr Msg Type: ISAKMP_CFG_SET (0x3)<br>
| Identifier: 0 (00 00)<br>
| next payload chain: setting previous 'ISAKMP Hash
Payload'.'next payload type' to current ISAKMP Mode Attribute
(14:ISAKMP_NEXT_MODECFG)<br>
| next payload chain: saving location 'ISAKMP Mode
Attribute'.'next payload type' in 'ModecfgR1'<br>
| pool 10.231.247.10-10.231.247.254: requesting one-time lease
for connection "xauth-psk"[1] 192.168.12.87 with '192.168.12.87'
and old address 192.168.12.87/32<br>
| pool 10.231.247.10-10.231.247.254: growing address pool from 0
to 1<br>
| entry spd_route
hash_table_entries.remote_client@0x55da52b90918 "xauth-psk"[1]
192.168.12.87 0.0.0.0/0 -<all>-> 10.231.247.10/32
deleted from hash table<br>
| entry spd_route
hash_table_entries.remote_client@0x55da52b90918 "xauth-psk"[1]
192.168.12.87 0.0.0.0/0 -<all>-> 10.231.247.10/32 added
to hash table bucket 0x55da514ba7c0<br>
| pool 10.231.247.10-10.231.247.254 lease 10.231.247.10 $2:
assign unused one-time lease to "xauth-psk"[1] 192.168.12.87 $2
with ID '192.168.12.87' and that.client 10.231.247.10/32; leases
1 in-use 1 free 0 reusable 0<br>
| a lease 10.231.247.10<br>
| ****emit ISAKMP ModeCfg attribute:<br>
| ModeCfg attr type: INTERNAL_IP4_ADDRESS (0x1)<br>
| emitting 4 raw bytes of IP_addr into ISAKMP ModeCfg attribute<br>
| IP_addr: 0a e7 f7 0a<br>
| emitting length of ISAKMP ModeCfg attribute: 4<br>
| ****emit ISAKMP ModeCfg attribute:<br>
| ModeCfg attr type: INTERNAL_IP4_SUBNET (0xd)<br>
| emitting 4 raw bytes of IP4_subnet into ISAKMP ModeCfg
attribute<br>
| IP4_subnet: 00 00 00 00<br>
| emitting 4 raw bytes of IP4_submsk into ISAKMP ModeCfg
attribute<br>
| IP4_submsk: 00 00 00 00<br>
| emitting length of ISAKMP ModeCfg attribute: 8<br>
| we are not sending a domain<br>
| We are not sending a banner<br>
| We are 0.0.0.0/0 so not sending CISCO_SPLIT_INC<br>
| no IKEv1 message padding required<br>
| emitting length of ISAKMP Mode Attribute: 28<br>
| HASH(1): addref key-key@0x55da52b81be0<br>
| result: newref trimmed key-key@0x55da52b97270 (64-bytes,
EXTRACT_KEY_FROM_KEY)(merge_symkey_bytes() +224
lib/libswan/crypt_symkey.c)<br>
| append_symkey_bytes: delref lhs-key@0x55da52b81be0<br>
| result: newref result-key@0x55da52b7b250 (64-bytes,
CONCATENATE_BASE_AND_DATA)(merge_symkey_bytes() +224
lib/libswan/crypt_symkey.c)<br>
| result: newref M-ID-key@0x55da52b7cac0 (68-bytes,
CONCATENATE_BASE_AND_DATA)(merge_symkey_bytes() +224
lib/libswan/crypt_symkey.c)<br>
| append_symkey_bytes: delref lhs-key@0x55da52b7b250<br>
| result: newref payload-key@0x55da52b7b250 (96-bytes,
CONCATENATE_BASE_AND_DATA)(merge_symkey_bytes() +224
lib/libswan/crypt_symkey.c)<br>
| append_symkey_bytes: delref lhs-key@0x55da52b7cac0<br>
| result: newref PRF HMAC inner hash-key@0x55da52b9a350
(32-bytes, EXTRACT_KEY_FROM_KEY)(merge_symkey_bytes() +224
lib/libswan/crypt_symkey.c)<br>
| result: newref PRF HMAC inner hash-key@0x55da52b7cac0
(16-bytes, EXTRACT_KEY_FROM_KEY)(symkey_from_bytes() +400
lib/libswan/crypt_symkey.c)<br>
| PRF HMAC inner hash: delref tmp-key@0x55da52b9a350<br>
| HASH(1): delref inner-key@0x55da52b7b250<br>
| result: newref result-key@0x55da52b7b250 (64-bytes,
CONCATENATE_BASE_AND_DATA)(merge_symkey_bytes() +224
lib/libswan/crypt_symkey.c)<br>
| result: newref result-key@0x55da52b9a350 (80-bytes,
CONCATENATE_BASE_AND_DATA)(merge_symkey_symkey() +251
lib/libswan/crypt_symkey.c)<br>
| append_symkey_symkey: delref lhs-key@0x55da52b7b250<br>
| HASH(1): delref hashed-inner-key@0x55da52b7cac0<br>
| HASH(1): delref key-key@0x55da52b97270<br>
| HASH(1): delref outer-key@0x55da52b9a350<br>
| XAUTH: mode config response HASH(1):<br>
| b2 26 79 e4 2f 41 88 d7 25 f5 cd 84 b7 46 c5 97
.&y./A..%....F..<br>
| no IKEv1 message padding required<br>
| emitting length of ISAKMP Message: 76<br>
| no IKEv1 message padding required<br>
| emitting length of ISAKMP Message: 76<br>
| sending 80 bytes for ModeCfg set through vipnet from
<server.address.redacted>:4500 to 192.168.12.87:4500 using
UDP (for #1)<br>
| 00 00 00 00 69 8b 70 ee 12 04 ce 2c 60 9a f2 9c
....i.p....,`...<br>
| 09 af c4 11 08 10 06 01 cb 07 91 0a 00 00 00 4c
...............L<br>
| eb de 33 51 6b ba b5 cc d0 0f 39 d5 90 29 25 6a
..3Qk.....9..)%j<br>
| 41 b4 57 c3 c8 6c ad d4 38 08 67 93 84 d0 e3 aa
A.W..l..8.g.....<br>
| 92 91 ea 78 46 44 6f 14 f6 3d f6 14 32 f1 17 ce
...xFDo..=..2...<br>
| #1 deleting EVENT_SA_EXPIRE<br>
| delref tt@0x55da52b9cf38(1->0) (destroy_timeout() +585
programs/pluto/server.c)<br>
| delref state-event@0x55da52b91c58(1->0) (delete_event()
+507 programs/pluto/timer.c)<br>
| #1 STATE_MODE_CFG_R1: retransmits: cleared<br>
| event_schedule_where: newref
EVENT_RETRANSMIT-pe@0x55da52b88ba8 timeout in 0.5 seconds for #1<br>
| newref tt@0x55da52b9d098(0->1) (schedule_timeout() +567
programs/pluto/server.c)<br>
| #1 STATE_MODE_CFG_R1: retransmits: first event in 0.5 seconds;
timeout in 60 seconds; limit of 12 retransmits; current time is
44714.269123<br>
| #1 spent 3.34 (3.34) milliseconds in process_packet_tail()<br>
| IKEv1 packet dropped<br>
| delref struct msg_digest@0x55da52b8ed38(1->0)
(process_iface_packet() +306 programs/pluto/demux.c)<br>
| delref logger@0x55da52b8c708(1->0) (process_iface_packet()
+306 programs/pluto/demux.c)<br>
| delref fd@NULL (process_iface_packet() +306
programs/pluto/demux.c)<br>
| delref fd@NULL (process_iface_packet() +306
programs/pluto/demux.c)<br>
| delref struct iface_endpoint@0x55da52b8db88(3->2)
(process_iface_packet() +306 programs/pluto/demux.c)<br>
| spent 4.07 (4.07) milliseconds in process_iface_packet()
reading and processing packet<br>
| spent 0.0105 (0.0104) milliseconds in udp_read_packet()
calling check_incoming_msg_errqueue()<br>
| newref struct msg_digest@0x55da52b8ed38(0->1)
(udp_read_packet() +386 programs/pluto/iface_udp.c)<br>
| addref struct iface_endpoint@0x55da52b8db88(2->3)
(udp_read_packet() +386 programs/pluto/iface_udp.c)<br>
| newref alloc logger@0x55da52b8c708(0->1) (udp_read_packet()
+386 programs/pluto/iface_udp.c)<br>
| *received 92 bytes from 192.168.12.87:4500 on vipnet
<server.address.redacted>:4500 using UDP<br>
| 69 8b 70 ee 12 04 ce 2c 60 9a f2 9c 09 af c4 11
i.p....,`.......<br>
| 08 10 05 01 b4 81 67 9e 00 00 00 5c d3 8e 5d 3b
......g....\..];<br>
| b5 79 ce 8f 91 fa a9 fb b3 ff 32 2b 21 9c 3f 22
.y........2+!.?"<br>
| e7 b8 49 2d 2d b5 c3 38 db 54 5c 76 58 2b a9 fb
..I--..8.T\vX+..<br>
| eb 16 e6 2f f2 a4 10 45 e0 1b ec 0e ca a0 0e 6f
.../...E.......o<br>
| 69 5d 0e 92 3a 71 24 0b 19 2c 35 75
i]..:q$..,5u<br>
| **parse ISAKMP Message:<br>
| initiator SPI: 69 8b 70 ee 12 04 ce 2c<br>
| responder SPI: 60 9a f2 9c 09 af c4 11<br>
| next payload type: ISAKMP_NEXT_HASH (0x8)<br>
| ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)<br>
| exchange type: ISAKMP_XCHG_INFO (0x5)<br>
| flags: ISAKMP_FLAG_v1_ENCRYPTION (0x1)<br>
| Message ID: 3028379550 (b4 81 67 9e)<br>
| length: 92 (00 00 00 5c)<br>
| processing version=1.0 packet with exchange
type=ISAKMP_XCHG_INFO (5)<br>
| peer and cookies match on #1; msgid=00000000 st_msgid=00000000
st_v1_msgid.phase15=cb07910a<br>
| p15 state object #1 found, in STATE_MODE_CFG_R1<br>
| State DB: found IKEv1 state #1 in MODE_CFG_R1
(find_v1_info_state)<br>
| #1 is idle<br>
| #1 idle<br>
| received encrypted packet from 192.168.12.87:4500<br>
| got payload 0x100 (ISAKMP_NEXT_HASH) needed: 0x100 opt: 0x0<br>
| byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is
0xf7 but should have been zero (ignored)<br>
"xauth-psk"[1] 192.168.12.87 #1: 9063-byte length of ISAKMP Hash
Payload is larger than can fit<br>
"xauth-psk"[1] 192.168.12.87 #1: malformed payload in packet<br>
| IKEv1 packet dropped<br>
| delref struct msg_digest@0x55da52b8ed38(1->0)
(process_iface_packet() +306 programs/pluto/demux.c)<br>
| delref logger@0x55da52b8c708(1->0) (process_iface_packet()
+306 programs/pluto/demux.c)<br>
| delref fd@NULL (process_iface_packet() +306
programs/pluto/demux.c)<br>
| delref fd@NULL (process_iface_packet() +306
programs/pluto/demux.c)<br>
| delref struct iface_endpoint@0x55da52b8db88(3->2)
(process_iface_packet() +306 programs/pluto/demux.c)<br>
| spent 0.715 (0.714) milliseconds in process_iface_packet()
reading and processing packet<br>
| timer_event_cb: processing
EVENT_RETRANSMIT-event@0x55da52b88ba8 for IKE SA #1 in state
MODE_CFG_R1<br>
| #1 deleting EVENT_RETRANSMIT<br>
| delref tt@0x55da52b9d098(1->0) (destroy_timeout() +585
programs/pluto/server.c)<br>
| delref state-event@0x55da52b88ba8(1->0) (timer_event_cb()
+227 programs/pluto/timer.c)<br>
| IKEv1 retransmit event<br>
| handling event EVENT_RETRANSMIT for 192.168.12.87
"xauth-psk"[1] 192.168.12.87 #1 keying attempt 0 of 0;
retransmit 1<br>
| #1 STATE_MODE_CFG_R1: retransmits: current time 44714.767407<br>
| #1 STATE_MODE_CFG_R1: retransmits: retransmit count 0 exceeds
limit? NO<br>
| #1 STATE_MODE_CFG_R1: retransmits: deltatime 0.5 exceeds
limit? NO<br>
| #1 STATE_MODE_CFG_R1: retransmits: monotime 0.498284 exceeds
limit? NO<br>
| event_schedule_where: newref
EVENT_RETRANSMIT-pe@0x55da52b88ba8 timeout in 0.5 seconds for #1<br>
| newref tt@0x55da52b9d408(0->1) (schedule_timeout() +567
programs/pluto/server.c)<br>
"xauth-psk"[1] 192.168.12.87 #1: STATE_MODE_CFG_R1:
retransmission; will wait 0.5 seconds for response<br>
| sending 80 bytes for EVENT_RETRANSMIT through vipnet from
<server.address.redacted>:4500 to 192.168.12.87:4500 using
UDP (for #1)<br>
| 00 00 00 00 69 8b 70 ee 12 04 ce 2c 60 9a f2 9c
....i.p....,`...<br>
| 09 af c4 11 08 10 06 01 cb 07 91 0a 00 00 00 4c
...............L<br>
| eb de 33 51 6b ba b5 cc d0 0f 39 d5 90 29 25 6a
..3Qk.....9..)%j<br>
| 41 b4 57 c3 c8 6c ad d4 38 08 67 93 84 d0 e3 aa
A.W..l..8.g.....<br>
| 92 91 ea 78 46 44 6f 14 f6 3d f6 14 32 f1 17 ce
...xFDo..=..2...<br>
| #1 spent 0.504 (0.502) milliseconds in timer_event_cb()
EVENT_RETRANSMIT<br>
| timer_event_cb: processing
EVENT_RETRANSMIT-event@0x55da52b88ba8 for IKE SA #1 in state
MODE_CFG_R1<br>
| #1 deleting EVENT_RETRANSMIT<br>
| delref tt@0x55da52b9d408(1->0) (destroy_timeout() +585
programs/pluto/server.c)<br>
| delref state-event@0x55da52b88ba8(1->0) (timer_event_cb()
+227 programs/pluto/timer.c)<br>
| IKEv1 retransmit event<br>
| handling event EVENT_RETRANSMIT for 192.168.12.87
"xauth-psk"[1] 192.168.12.87 #1 keying attempt 0 of 0;
retransmit 2<br>
</font></blockquote>
<font face="monospace">And then finally gives up and moves on to
sending the delete notification:<br>
</font>
<blockquote><font face="monospace">| handling event EVENT_RETRANSMIT
for 192.168.12.87 "xauth-psk"[1] 192.168.12.87 #1 keying attempt
0 of 0; retransmit 8<br>
| #1 STATE_MODE_CFG_R1: retransmits: current time 44778.295539<br>
| #1 STATE_MODE_CFG_R1: retransmits: retransmit count 7 exceeds
limit? NO<br>
| #1 STATE_MODE_CFG_R1: retransmits: deltatime 64 exceeds limit?
YES<br>
| #1 STATE_MODE_CFG_R1: retransmits: monotime 64.026416 exceeds
limit? YES<br>
"xauth-psk"[1] 192.168.12.87 #1: STATE_MODE_CFG_R1: 60 second
timeout exceeded after 7 retransmits. No response (or no
acceptable response) to our IKEv1 message<br>
| pstats #1 ikev1.isakmp re-failed too-many-retransmits<br>
| FOR_EACH_STATE_... in (find_phase1_state() +1898
programs/pluto/state.c)<br>
| found "xauth-psk"[1] 192.168.12.87 #1<br>
| matches: 1<br>
| should_send_delete: yes<br>
"xauth-psk"[1] 192.168.12.87 #1: deleting state
(STATE_MODE_CFG_R1) aged 64.077151s and sending notification<br>
| pstats #1 ikev1.isakmp deleted completed<br>
| #1 main thread spent 10.1 (10.1) milliseconds helper thread
spent 1.06 (1.06) milliseconds in total<br>
| suspend: no MD saved in state #1 (delete_state_tail() +1013
programs/pluto/state.c)<br>
| FOR_EACH_STATE_... in (find_phase1_state() +1898
programs/pluto/state.c)<br>
| found "xauth-psk"[1] 192.168.12.87 #1<br>
| matches: 1<br>
| should_send_delete: yes<br>
| #1 send IKEv1 delete notification for STATE_MODE_CFG_R1<br>
| opening output PBS delete msg<br>
... ...<br>
</font></blockquote>
<font face="monospace">And in any case it doesn't seem like the
client did any any further "login" after the PSK authenitcation,
which seems quite odd as the client android app claims to be doing
XAUTH and asks for username and password each time it connects.
Any thoughts on what's happening would be greatly appreciated.<br>
<br>
Thank you very much.<br>
<br>
Wolf<br>
</font><br>
<div class="moz-cite-prefix">On 17/03/2022 02:26, 1one.w01f wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e0c3ee68-d65d-88f0-0ee2-ba34130842ee@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<font face="monospace">Dear Andrew,<br>
<br>
Thanks for the analysis and suggestion. Now I have these options
commented out in ipsec.conf:<br>
</font>
<blockquote><font face="monospace"> # leftxauthserver=yes<br>
# rightxauthclient=yes<br>
# xauthby=file<br>
</font></blockquote>
<font face="monospace">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:<br>
</font>
<blockquote><font face="monospace">| received encrypted packet
from 192.168.12.87:4500<br>
| got payload 0x100 (ISAKMP_NEXT_HASH) needed: 0x100 opt: 0x0<br>
| byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is
0xf7 but should have been zero (ignored)<br>
"xauth-psk"[1] 192.168.12.87 #1: 9063-byte length of ISAKMP
Hash Payload is larger than can fit<br>
"xauth-psk"[1] 192.168.12.87 #1: malformed payload in packet<br>
| IKEv1 packet dropped<br>
<br>
</font></blockquote>
<font face="monospace">And this is what the android client app
printed to logcat:<br>
</font>
<blockquote><font face="monospace">I FORTIKE : 2022-03-16
16:39:28.916 Adding remote and local NAT-D payloads.</font><br>
<font face="monospace">I FORTIKE : 2022-03-16 16:39:28.916
Hashing <server.address.redacted>[4500] with algo #1
(NAT-T forced)</font><br>
<font face="monospace">I FORTIKE : 2022-03-16 16:39:28.916
Hashing 192.168.12.87[4500] with algo #1 (NAT-T forced)</font><br>
<font face="monospace">I FORTIKE : 2022-03-16 16:39:28.916 Rekey
life time: 28500</font><br>
<font face="monospace">I FORTIKE : 2022-03-16 16:39:28.917
ISAKMP-SA established
192.168.12.87-<server.address.redacted>
spi:d2ef9e98883a5b6e:9521bbd1fdc60297</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:28.930 Short
payload</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:29.425 Short
payload</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:29.929 Short
payload</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:30.932 Short
payload</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:32.929 Short
payload</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:36.936 Short
payload</font><br>
<font face="monospace">W FORTIKE : 2022-03-16 16:39:44.979 Short
payload</font><br>
<font face="monospace">I FortiClient VPN: Could not establish
session on the IPsec daemon</font><br>
<font face="monospace">I FORTIKE : 2022-03-16 16:39:53.994
FortiIKE daemon exiting...</font><br>
<font face="monospace">I FortiClient VPN: Connection failed:
Could not establish session on the IPsec daemon</font><br>
</blockquote>
<font face="monospace">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?<br>
<br>
Thanks.<br>
<br>
Wolf</font><br>
<br>
<div class="moz-cite-prefix">On 16/03/2022 07:25, Andrew Cagney
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJeAr6uom+h4TqWUG92tr=6D2qJqfW-poF-mNMquw52LXBG_LA@mail.gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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]
<a class="moz-txt-link-freetext" href="https://testing.libreswan.org/v4.6-409-g0dd023c306-main/xauth-pluto-04/OUTPUT/east.pluto.log.gz" moz-do-not-send="true">https://testing.libreswan.org/v4.6-409-g0dd023c306-main/xauth-pluto-04/OUTPUT/east.pluto.log.gz</a>
if the xauth parts of the config are dropped, does it get further?
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>