Cisco ASA VyOS 1.3-rolling-202006081325 INVALID_ID_INFORMATION error notify

Hi

Im trying to setup an IPSec VPN with a Cisco ASA, and a 1.3-rolling-202006081325 and I see this odd INVALID_ID_INFORMATION error notify errors.
Hopefully someone can enlighten me on what I am doing wrong?
The Cisco side is not being helpful regarding troubleshooting or even responding.
Errors returned:

sudo ipsec up peer-xxx.xxx.79.242-tunnel-0 
initiating Main Mode IKE_SA peer-xxx.xxx.79.242-tunnel-0[30] to xxx.xxx.79.242
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from xxx.xxx.40.5[500] to xxx.xxx.79.242[500] (180 bytes)
received packet: from xxx.xxx.79.242[500] to xxx.xxx.40.5[500] (128 bytes)
parsed ID_PROT response 0 [ SA V V ]
received NAT-T (RFC 3947) vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from xxx.xxx.40.5[500] to xxx.xxx.79.242[500] (244 bytes)
received packet: from xxx.xxx.79.242[500] to xxx.xxx.40.5[500] (304 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: XX:XX:XX:XX:XX:b1:XX:XX:XX:XX:XX:xxxx:xxxx:a7:4e:d3
received unknown vendor ID: XX:XX:XX:XX:XX:65:XX:XX:XX:XX:XX:xxxx:xxxx:50:01:00
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from xxx.xxx.40.5[500] to xxx.xxx.79.242[500] (108 bytes)
received packet: from xxx.xxx.79.242[500] to xxx.xxx.40.5[500] (92 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
IKE_SA peer-xxx.xxx.79.242-tunnel-0[30] established between xxx.xxx.40.5[xxx.xxx.40.5]...xxx.xxx.79.242[xxx.xxx.79.242]
scheduling reauthentication in 3036s
maximum IKE_SA lifetime 3576s
generating QUICK_MODE request 728652815 [ HASH SA No ID ID ]
sending packet: from xxx.xxx.40.5[500] to xxx.xxx.79.242[500] (172 bytes)
received packet: from xxx.xxx.79.242[500] to xxx.xxx.40.5[500] (220 bytes)
parsed INFORMATIONAL_V1 request 3092100239 [ HASH N(INVAL_ID) ]
received INVALID_ID_INFORMATION error notify
establishing connection 'peer-xxx.xxx.79.242-tunnel-0' failed

Configs:

 close-action restart
 dead-peer-detection {
     action restart
     interval 30
     timeout 90
 }
 ikev2-reauth no
 key-exchange ikev1
 lifetime 3600
 proposal 1 {
     encryption aes256
     hash sha1
 }
lifetime 28800
 pfs disable
 proposal 1 {
     encryption aes256
     hash sha1
 }

Cisco side claims to have this:

crypto map VPN 1340 match remote-side
crypto map VPN 1340 set peer xxx.xxx.40.5
crypto map VPN 1340 set ikev1 transform-set ESP-AES-256-SHA
crypto map VPN 1340 set security-association lifetime seconds 3600

Phase2 fails.
Both config snippets lack detail to see what’s wrong

Thanks!
What can I pull out to show whats wrong?
Cisco side claims thats their entire config

The more information available for troubleshooting, the better chance of finding the problem.
At least the VPN section of VyOS and the relevant sections from Cisco.
Off topic, but a VyOS update is also recommended. Yours is over two years old.

Thanks about updating VyOS, but its largely out of my hands.

Regarding the VPN configuration, I already posted the IKE and ESP portions of the VyOS side, and all I was provided to configure, from the Cisco ASA side, in the first post.
Im not sure if I left anything relevant out, but I’m posting here again:

Configs:

IKE:
 close-action restart
 dead-peer-detection {
     action restart
     interval 30
     timeout 90
 }
 ikev2-reauth no
 key-exchange ikev1
 lifetime 3600
 proposal 1 {
     encryption aes256
     hash sha1
 }
ESP:
lifetime 28800
 pfs disable
 proposal 1 {
     encryption aes256
     hash sha1
 }

Cisco side claims to have this:

crypto map VPN 1340 match remote-side
crypto map VPN 1340 set peer xxx.xxx.40.5
crypto map VPN 1340 set ikev1 transform-set ESP-AES-256-SHA
crypto map VPN 1340 set security-association lifetime seconds 3600

Ike lifetime shouldn’t be less then esp lifetime

Thank you.
You were probably right about the difference in configuration.
They couldnt state which phase was wrong, but they fixed it at their end.