strongSwan - Issue #3597
IPSec Client on CentOS 8 - Can't connect using ShrewSoft VPN config file
15.10.2020 17:32 - Jon Doe

ステータス:

Feedback

優先度:

Normal担当者:
カテゴリ:

configuration

Affected version:

5.8.2

Resolution:

説明A business partner of ours sent us a ShrewSoft VPN config file and I was tasked to implement it on a CentOS8-VM.
ShrewSoft config.vpn

n:version:4
s:network-host:1.2.3.4 //not real IP
n:network-ike-port:500
s:client-auto-mode:pulln:network-mtu-size:1380
s:client-iface:virtualn:client-addr-auto:1
s:network-natt-mode:enable
n:network-natt-port:4500
n:network-natt-rate:15
s:network-frag-mode:enable
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:1
n:client-wins-auto:1
s:auth-method:mutual-psk
s:ident-client-type:fqdn
s:ident-server-type:fqdn
s:ident-client-data:Names:ident-server-data:nameb:auth-mutual-psk:lakfdjdflödfjsadlfjksdalkfj //not reals:phase1-exchange:aggressive
n:phase1-dhgroup:2s:phase1-cipher:aes
n:phase1-keylen:128
s:phase1-hash:md5
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0s:phase2-transform:esp-aes
n:phase2-keylen:128
s:phase2-hmac:md5
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2n:phase2-life-secs:3600
n:phase2-life-kbytes:0
s:policy-level:auton:policy-nailed:0n:policy-list-auto:0
s:policy-list-include:192.168.111.0 / 255.255.255.010.10.2024

PSK

1/4

s:client-saved-username:As a VPN client I choose StrongSwan, installed it via "dnf install strongswan" and made the following changes:/etc/strongswan/ipsec.secrets# ipsec.secrets - strongSwan IPsec secrets file
1.2.3.4 : PSK lakfdjdflödfjsadlfjksdalkfj // same IP

as"s:network-host"from

ShrewSoft

Configfile

After a lot of trial and error, my ipsec.conf looks the following:/etc/strongswan/ipsec.conf#ipsec.conf#basicconfig-strongSwan

IPsec

configuration

fileconfiguration

setup
##

strictcrlpolicy=yes
uniqueids = noconn%default
ikelifetime=86400m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=psk

connrandomname
aggressive=yes
esp=aes128-md5!
ike=aes128-md5-modp1024!
left=%defaultroute
leftid=Name //Same as "s:ident-client-data" from ShrewSoft Config Fileright=1.2.3.4 // same IP as "s:ident-server-data" from ShrewSoft Config filerightid=name //Same as "s:ident-server-data:name" from ShrewSoft Config Filerightsubnet=192.168.111.0/24
auto=add

After restarting strongswan and running "strongswan up randomname", i get the following output:

initiating Aggressive Mode IKE̲SA randomname[1] to 1.2.3.4
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]sending packet: from 5.6.7.8"[500] to 1.2.3.4[500] (368 bytes) //5.6.7.8 is the IP of the CentOs
nreceived packet: from 1.2.3.4[500] to 5.6.7.8[500] (444 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH V V V V V V NAT-D NAT-D ]received unknown vendor ID: 1a:ff:b3:68:06:b3:1a:d4:de:4e:6c:11:1c:36:a6:41 //not real vendor ID
received XAuth vendor ID
received DPD vendor ID
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received draft-ietf-ipsec-nat-t-ike-03 vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES̲CBC̲128/HMAC̲MD5̲96/PRF̲HMAC̲MD5/MODP̲1024
calculated HASH does not match HASH payload
generating INFORMATIONAL̲V1 request 715948327 [ HASH N(AUTH̲FAILED) ]sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (92 bytes)
establishing connection 'randomname' failed

8It looks the hashes of the PSK don't match, but I do not understand why.
When importing the vpn config from above into the ShrewSoft VPN running on a windows machine, it works.
I'm not really fimilar with linux as you may can tell, so don't be to hard on me please.

10.10.2024

2/4

VM

Strongswan

履歴#1 - 16.10.2020 15:20 - Tobias Brunner- ステータス を New から Feedback に変更

It looks the hashes of the PSK don't match, but I do not understand why.

Probably because the PSK is wrong.
#2 - 20.10.2020 15:26 - Jon Doe- ファイル 1.png を追加- ファイル 2.png を追加- ファイル 3.png を追加- ファイル 4.png を追加
Tobias Brunner wrote:
It looks the hashes of the PSK don't match, but I do not understand why.

Probably because the PSK is wrong.

Yep, that was it. I received a new PSK in addition to a new VPN-config on the customers site, see below (1, 2, 3, 4)
I edited my client-side ipsec.conf like this:connrandomname
keyexchange=ikev2
leftauth=psk
rightauth=psk
ike=aes256-sha256-modp2048
dpdaction=restart
dpddelay=30s
left=%defaultrouteright=1.2.3.4
auto=add

When trying to connect, I run into the following problem:

initiating IKE̲SA randomname[1] to 1.2.3.4
generating IKE̲SA̲INIT request 0 [ SA KE No N(NATD̲S̲IP) N(NATD̲D̲IP) N(FRAG̲SUP) N(HASH̲ALG) N(REDIR̲SUP) ]sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (1316 bytes)
received packet: from 5.6.7.8[500] to 1.2.3.4[500] (503 bytes)
parsed IKE̲SA̲INIT response 0 [ SA KE No N(NATD̲S̲IP) N(NATD̲D̲IP) N(HASH̲ALG) N(FRAG̲SUP) CERTREQ V ]received unknown vendor ID: 1a:ff:b3:68:06:b3:1a:d4:de:4e:6c:11:1c:36:a6:41
selected proposal: IKE:AES̲CBC̲256/HMAC̲SHA2̲256̲128/PRF̲HMAC̲SHA2̲256/MODP̲2048
local host is behind NAT, sending keep alives
received 1 cert requests for an unknown ca
no IDi configured, fall back on IP address
authentication of '5.6.7.8' (myself) with pre-shared key
establishing CHILD̲SA randomname{1}generating IKE̲AUTH request 1 [ IDi N(INIT̲CONTACT) IDr AUTH SA TSi TSr N(MOBIKE̲SUP) N(NO̲ADD̲ADDR) N(EAP̲ONLY)N̲SUP) ]sending packet: from 5.6.7.8[4500] to 1.2.3.4[4500] (320 bytes)
received packet: from 1.2.3.4[4500] to 5.6.7.8[4500] (80 bytes)
parsed IKE̲AUTH response 1 [ N(AUTH̲FAILED) ]received AUTHENTICATION̲FAILED notify error
establishing connection 'randomname' failed
I can't make sense of this.
#3 - 21.10.2020 16:38 - Tobias Brunner
Either the PSK is wrong or the identities don't match, but only the log of the other end could tell you (if it actually does is a different matterentirely).

10.10.2024

3/4

N(MNo idea what it means if you select "No identity" in the GUI or how the value "unknown" is eventually matched to the actual identities strongSwansends (if you don't configure left¦rightid the IP addresses will be sent when using PSK authentication).
Also, since PFS is enabled in the remote config, you probably should configure an ESP proposal (just use the same you have configured for IKE) toavoid problems during rekeying later.
#4 - 03.04.2023 13:33 - Tobias BrunnerAs pointed out by IRC user philha recently, auth-mutual-psk stores the PSK in base64-encoding, not the actual PSK. So to use it with strongSwan(e.g. in swanctl.conf or ipsec.secrets), either prefix it with 0s (and for swanctl.conf wrap it in "" as well if it contains = characters), or decode it first(e.g. via echo -n "<base64value>" ¦ base64 -d). Note that the latter won't work for PSKs with non-printable binary characters.

ファイル
2.png

26.6 KB

20.10.2020

Jon Doe

1.png

31.2 KB

20.10.2020

Jon Doe

3.png

7.2 KB

20.10.2020

Jon Doe

4.png

6.65 KB

20.10.2020

Jon Doe10.10.2024

4/4