Project

General

Profile

Issue #3597

IPSec Client on CentOS 8 - Can't connect using ShrewSoft VPN config file

Added by Jon Doe 14 days ago. Updated 8 days ago.

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

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.

2.png (26.6 KB) 2.png Jon Doe, 20.10.2020 14:49
1.png (31.2 KB) 1.png Jon Doe, 20.10.2020 14:49
3.png (7.2 KB) 3.png Jon Doe, 20.10.2020 14:49
4.png (6.65 KB) 4.png Jon Doe, 20.10.2020 14:49

History

#1 Updated by Tobias Brunner 13 days 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 9 days 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 8 days 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.

Also available in: Atom PDF