Issue #3597
IPSec Client on CentOS 8 - Can't connect using ShrewSoft VPN config file
Description
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:pull n:network-mtu-size:1380 s:client-iface:virtual n: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:Name s:ident-server-data:name b:auth-mutual-psk:lakfdjdflödfjsadlfjksdalkfj //not real PSK s:phase1-exchange:aggressive n:phase1-dhgroup:2 s: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:0 s:phase2-transform:esp-aes n:phase2-keylen:128 s:phase2-hmac:md5 s:ipcomp-transform:disabled n:phase2-pfsgroup:2 n:phase2-life-secs:3600 n:phase2-life-kbytes:0 s:policy-level:auto n:policy-nailed:0 n:policy-list-auto:0 s:policy-list-include:192.168.111.0 / 255.255.255.0 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 Config file
After a lot of trial and error, my ipsec.conf looks the following:
/etc/strongswan/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn %default
ikelifetime=86400m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=psk
conn randomname
aggressive=yes
esp=aes128-md5!
ike=aes128-md5-modp1024!
left=%defaultroute
leftid=Name //Same as "s:ident-client-data" from ShrewSoft Config File
right=1.2.3.4 // same IP as "s:ident-server-data" from ShrewSoft Config file
rightid=name //Same as "s:ident-server-data:name" from ShrewSoft Config File
rightsubnet=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 8 VM Strongswan is running on received 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
It 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.
History
#1 Updated by Tobias Brunner over 1 year ago
- Status changed from New to Feedback
It looks the hashes of the PSK don't match, but I do not understand why.
Probably because the PSK is wrong.
#2 Updated by Jon Doe over 1 year ago
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:
conn randomname
keyexchange=ikev2
leftauth=psk
rightauth=psk
ike=aes256-sha256-modp2048
dpdaction=restart
dpddelay=30s
left=%defaultroute
right=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(MSG_ID_SYN_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 Updated by Tobias Brunner over 1 year ago
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 matter entirely).
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 strongSwan sends (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) to avoid problems during rekeying later.