Project

General

Profile

Issue #3322

Error - invalid HASH_V1 payload length, decryption failed

Added by Maksym Dotsenko 2 months ago. Updated 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.7.2
Resolution:

Description

Hi to all!

I have some problems configuring IPSEC between Linux - Cisco. I would appreciate it if you could take a look at the Linux config files. Unfortunately, I don't have a lot of experience in strongswan and done the conf. as I see it.
Thank you in advance.

MY SIDE:
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Linux strongSwan U5.7.2/K4.19.75-v7+

CISCO SIDE

! policy1

crypto isakmp policy 152

encr aes 256

hash sha

group 5

lifetime 86400

!

! policy2

crypto ipsec transform-set TS-AES-SHA256 esp-aes 256 esp-sha256-hmac

 mode tunnel

!

crypto keyring C-AVILOO

  pre-shared-key address 178.115.235.78 key *****************

!

crypto map vpn 89 ipsec-isakmp

 set peer 178.115.235.78

set transform-set TS-AES-SHA256

 set isakmp-profile C-AVILOO

match address C-AVILOO

reverse-route static

!

ip access-list extended C-AVILOO

permit ip host 172.19.254.89 host 178.115.131.146

    permit ip 10.0.0.0 0.0.31.255 128.0.0.0 127.255.255.255

    permit ip 10.0.0.0 0.0.31.255 64.0.0.0 63.255.255.255

    permit ip 10.0.0.0 0.0.31.255 32.0.0.0 31.255.255.255

    permit ip 10.0.0.0 0.0.31.255 16.0.0.0 15.255.255.255

    permit ip 10.0.0.0 0.0.31.255 8.0.0.0 7.255.255.255

    permit ip 10.0.0.0 0.0.31.255 4.0.0.0 3.255.255.255

    permit ip 10.0.0.0 0.0.31.255 2.0.0.0 1.255.255.255

    permit ip 10.0.0.0 0.0.31.255 1.0.0.0 0.255.255.255

!        

log.file (5.37 KB) log.file MY SIDE Maksym Dotsenko, 27.01.2020 11:04
iptables.rules (4.24 KB) iptables.rules MY SIDE Maksym Dotsenko, 27.01.2020 11:04
ipsec.conf (641 Bytes) ipsec.conf MY SIDE Maksym Dotsenko, 27.01.2020 11:04
ipsec.secrets (314 Bytes) ipsec.secrets MY SIDE Maksym Dotsenko, 27.01.2020 11:04

History

#1 Updated by Maksym Dotsenko 2 months ago

Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.19.75-v7+, armv7l):
uptime: 48 minutes, since Jan 27 09:23:42 2020
malloc: sbrk 1220608, mmap 0, used 310000, free 910608
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon aes rc2 sha2 sha1 md5 mgf1 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 counters
Listening IP addresses:
192.168.0.150
Connections:
cisco: %any...194.24.131.1 IKEv1
cisco: local: [178.115.235.78] uses pre-shared key authentication
cisco: remote: [194.24.131.1] uses pre-shared key authentication
cisco: child: 0.0.0.0/0 === 10.0.0.0/19 TUNNEL
Security Associations (1 up, 0 connecting):
cisco1: ESTABLISHED 48 minutes ago, 192.168.0.150[178.115.235.78]...194.24.131.1[194.24.131.1]
cisco1: IKEv1 SPIs: 0b8b43d67511a785_i* ed782263d9e58bb4_r, pre-shared key reauthentication in 22 hours
cisco1: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536

#2 Updated by Tobias Brunner 2 months ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Priority changed from High to Normal

The informational doesn't seems relevant. But apparently your Quick Mode proposal (ESP) doesn't match:

Jan 27 09:23:42 raspberrypi charon: 10[ENC] generating QUICK_MODE request 2270601801 [ HASH SA No ID ID ]
Jan 27 09:23:42 raspberrypi charon: 10[NET] sending packet: from 192.168.0.150[4500] to 194.24.131.1[4500] (204 bytes)
Jan 27 09:23:42 raspberrypi charon: 12[NET] received packet: from 194.24.131.1[4500] to 192.168.0.150[4500] (92 bytes)
Jan 27 09:23:42 raspberrypi charon: 12[ENC] parsed INFORMATIONAL_V1 request 3838561195 [ HASH N(NO_PROP) ]
Jan 27 09:23:42 raspberrypi charon: 12[IKE] received NO_PROPOSAL_CHOSEN error notify

Check the peer's log.

#3 Updated by Maksym Dotsenko 2 months ago

Hi Tobias,

Thank you for the prompt response. Can you please take a look at what actually not match from my side? I am struggling already couple of days without any success
Regards, Max

Phase1 is already UP and Active

IKEv1 SA: local 194.24.131.1/4500 remote 178.115.235.78/4500 Active

When using the UDP port 4500, even Phase2 is UP

Session status: UP-IDLE

Peer: 178.115.235.78 port 4500 fvrf: (none) ivrf: C-AVILOO

Phase1_id: 178.115.235.78

But, there is another Phase2 state which uses port500 and unfortunately, this is always DOWN.

Session status: DOWN

Peer: 178.115.235.78 port 500 fvrf: (none) ivrf: C-AVILOO

Phase1_id: (none)

I do not understand why port ports are in use. 4500 is pointing to a NAT configuration. I assume we need accordingly a configuration update.

IPSEC FLOW: permit ip 10.0.0.0/255.255.224.0 8.0.0.0/248.0.0.0
Active SAs: 0, origin: crypto map
Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 656 drop 0 life (KB/Sec) 0/0
IPSEC FLOW: permit ip 10.0.0.0/255.255.224.0 1.0.0.0/255.0.0.0
Active SAs: 0, origin: crypto map
Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 657 drop 0 life (KB/Sec) 0/0

#4 Updated by Tobias Brunner 2 months ago

Can you please take a look at what actually not match from my side?

Only the peer really knows. So again, check the log there. But it's possible that the algorithms are OK, while the subnets are not (the reurned error would be wrong, though). Are you sure about leftsubnet=0.0.0.0/0?

When using the UDP port 4500, even Phase2 is UP

That sounds strange. But it's IKEv1 and Cisco so... Anyway, you could try forcing UDP encap (forceencaps option).

Also available in: Atom PDF