<div dir="ltr"><div>This is the output of the "statusall" command.</div><div>Keep trying...</div><div><br></div>Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-16-amd64, x86_64):<br> uptime: 60 seconds, since Jul 14 12:09:18 2021<br> malloc: sbrk 2568192, mmap 0, used 430208, free 2137984<br> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1<br> loaded plugins: charon aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown<br>Listening IP addresses:<br> 200.xxx.xxx.xxx<br> 190.xxx.xxx.xxx<br>Connections:<br> ciscoios: 190.xxx.xxx.xxx...200.xxx.xxx.xxx IKEv1<br> ciscoios: local: [190.xxx.xxx.xxx] uses pre-shared key authentication<br> ciscoios: remote: [200.xxx.xxx.xxx] uses pre-shared key authentication<br> ciscoios: child: 200.xxx.xxx.0/24 === <a href="http://192.168.77.0/24">192.168.77.0/24</a> TUNNEL<br> ciscoios2: child: 200.xxx.xxx.0/24 === <a href="http://10.30.200.0/24">10.30.200.0/24</a> TUNNEL<br> ciscoios3: child: 200.xxx.xxx.0/24 === <a href="http://192.3.59.0/24">192.3.59.0/24</a> TUNNEL<br>Security Associations (0 up, 1 connecting):<br> ciscoios[1]: CONNECTING, 190.xxx.xxx.xxx[190.xxx.xxx.xxx]...200.xxx.xxx.xxx[%any]<br> ciscoios[1]: IKEv1 SPIs: 40e31fe9f8a889ee_i* a103e7f136b195ea_r<br> ciscoios[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024<br> ciscoios[1]: Tasks queued: QUICK_MODE QUICK_MODE QUICK_MODE <br> ciscoios[1]: Tasks active: ISAKMP_VENDOR MAIN_MODE <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié, 14 jul 2021 a las 9:00, Tobias Brunner (<<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Marcelo,<br>
<br>
The first two Main Mode exchanges apparently work fine, but then there <br>
is no response to the third request, which is encrypted. So it's <br>
possible that the PSK is incorrect and the peer can't decrypt the message.<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div>