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.