topic Re: Using StrongSwan to connect R81.10 GW using xauth-hybrid in SASE and Remote Access

Using StrongSwan to connect R81.10 GW using xauth-hybrid

SwitchW0rm — Wed, 22 Mar 2023 18:50:50 GMT

I try to connect to a r81.10 gateway using a linux distribution with strongswan.
Gateway accepts user:password only. Tested with Windows Version of Checkpoint Endpoint Software. Have to use ikev1.

The error looks like a PSK would not match but xauth-hybrid should be used. so the server is verified by certificate (it is exported from smart console and imported to strongswan) und the client with username:password.

I can not find whats wrong.

Anyone can give a hint?

ipsec.conf:

config setup
charondebug="ike 4,knl 4,cfg 3,chd 4"

conn checkpointvpn
type=tunnel
leftfirewall=yes
rightauth=pubkey
leftauth=xauth #no difference in using xauth-eap or xauth-hydrid
keyexchange=ikev1
xauth_identity=<username>
leftsourceip=%config
right=1.2.3.4 # r81.10 gateway ip
rightid=1.2.3.4
rightsubnet=0.0.0.0/0
rightcert=gateway.pem
ike=aes256-sha1-modp1024
esp=3des-sha1
lifetime=1h
reauth=yes
rekey=yes
margintime=1m
auto=add
dpdaction=restart
dpddelay=30s
dpdtimeout=60s

ipsec.secrets:

<username> : EAP "<password>"

ipsec version:
Linux strongSwan U5.9.8/K6.1.0-kali5-amd64
University of Applied Sciences Rapperswil, Switzerland

ipsec up checkpointvpn:
initiating Main Mode IKE_SA checkpointvpn[1] to 1.2.3.4
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.178.94[500] to 1.2.3.4[500] (240 bytes)
received packet: from 1.2.3.4[500] to 192.168.178.94[500] (124 bytes)
parsed ID_PROT response 0 [ SA V V ]
received FRAGMENTATION vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.178.94[500] to 1.2.3.4[500] (244 bytes)
received packet: from 1.2.3.4[500] to 192.168.178.94[500] (232 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 192.168.178.94[4500] to 1.2.3.4[4500] (108 bytes)
received packet: from 1.2.3.4[4500] to 192.168.178.94[4500] (40 bytes)
parsed INFORMATIONAL_V1 request 812249139 [ N(INVAL_ID) ]
ignoring unprotected INFORMATIONAL from 1.2.3.4
message verification failed
ignore malformed INFORMATIONAL request
INFORMATIONAL_V1 request with message ID 812249139 processing failed
sending retransmit 1 of request message ID 0, seq 3
sending packet: from 192.168.178.94[4500] to 1.2.3.4[4500] (108 bytes)
sending retransmit 2 of request message ID 0, seq 3
sending packet: from 192.168.178.94[4500] to 1.2.3.4[4500] (108 bytes)

Re: Using StrongSwan to connect R81.10 GW using xauth-hybrid

PhoneBoy — Wed, 22 Mar 2023 22:02:53 GMT

Why do you have to use IKEv1?
I’m pretty sure we only tested this with IKEv2.

Re: Using StrongSwan to connect R81.10 GW using xauth-hybrid

SwitchW0rm — Thu, 23 Mar 2023 08:48:03 GMT

the gateway settings work for a variety of windows clients in production. my edge case does not warrant any changes including downtime and possible disruptions. so it is fix.

Global Properties -> Remote Access -> VPN - Authentication and Encryption
Encryption method
IKEv1 only checked

so i guess IKEv2 is forbidden.

Re: Using StrongSwan to connect R81.10 GW using xauth-hybrid

SwitchW0rm — Thu, 23 Mar 2023 14:59:34 GMT

i managed to get the first step done. authenticate the gateway side by give a full identiy user@domain. but after this still stucks. gateway side says: malformed packet.

charon-cmd --host 1.2.3.4 --identity user@domain.local --xauth-username user@domain.local --ike-proposal aes256-sha1-modp1024 --profile ikev1-hybrid --cert /home/xxx/Desktop/xxxxxx.pem
00[PTS] TPM 2.0 - could not load "libtss2-tcti-tabrmd.so.0"
00[LIB] plugin 'tpm': failed to load - tpm_plugin_create returned NULL
00[LIB] providers loaded by OpenSSL: default legacy
00[LIB] created TUN device: ipsec1
00[LIB] dropped capabilities, running as uid 0, gid 0
00[DMN] Starting charon-cmd IKE client (strongSwan 5.9.8, Linux 6.1.0-kali5-amd64, x86_64)
00[LIB] loaded plugins: charon-cmd ldap pkcs11 aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 sshkey pem openssl gcrypt pkcs8 af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac kdf ctr ccm gcm drbg curl kernel-libipsec kernel-netlink resolve socket-default bypass-lan eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls xauth-generic
00[JOB] spawning 16 worker threads
09[IKE] installed bypass policy for 192.168.178.0/24
11[IKE] initiating Main Mode IKE_SA cmd[1] to 1.2.3.4
09[KNL] error installing route with policy fe80::/64 === fe80::/64 out
11[ENC] generating ID_PROT request 0 [ SA V V V V V ]
09[IKE] installed bypass policy for fe80::/64
09[IKE] interface change for bypass policy for fe80::/64 (from ipsec0 to eth0)
09[KNL] error installing route with policy fe80::/64 === fe80::/64 out
11[NET] sending packet: from 192.168.178.94[47267] to 1.2.3.4[4500] (180 bytes)
13[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[47267] (124 bytes)
13[ENC] parsed ID_PROT response 0 [ SA V V ]
13[IKE] received FRAGMENTATION vendor ID
13[IKE] received NAT-T (RFC 3947) vendor ID
13[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
13[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
13[NET] sending packet: from 192.168.178.94[47267] to 1.2.3.4[4500] (244 bytes)
12[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[47267] (232 bytes)
12[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
12[IKE] local host is behind NAT, sending keep alives
12[IKE] remote host is behind NAT
12[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
12[NET] sending packet: from 192.168.178.94[38829] to 1.2.3.4[4500] (124 bytes)
02[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[38829] (1756 bytes)
02[ENC] parsed ID_PROT response 0 [ ID CERT CERT SIG N((24576)) V ]
02[IKE] received DPD vendor ID
02[IKE] received end entity cert "O=management..xxxxxx, CN=xxxxxx VPN Certificate"
02[IKE] received issuer cert "O=management..xxxxxx"
02[CFG]   using trusted certificate "O=management..xxxxxx, CN=xxxxxx VPN Certificate"
02[CFG]   using untrusted intermediate certificate "O=management..xxxxxx"
02[CFG]   self-signed certificate "O=management..xxxxxx" is not trusted
02[CFG] checking certificate status of "O=management..xxxxxx, CN=xxxxxx VPN Certificate"
02[CFG]   fetching crl from 'O=management..xxxxxx, CN=ICA_CRL4' ...
02[LIB] unable to fetch from O=management..xxxxxx, CN=ICA_CRL4, no capable fetcher found
02[CFG] crl fetching failed
02[CFG]   fetching crl from 'http://fwmgt.domain.local:18264/ICA_CRL4.crl' ...
02[LIB] libcurl request failed [7]: Failed to connect to fwmgt.domain.local port 18264 after 0 ms: Couldn't connect to server
02[CFG] crl fetching failed
02[CFG] certificate status is not available
02[IKE] authentication of '1.2.3.4' with RSA_EMSA_PKCS1_NULL successful
16[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[38829] (1756 bytes)
16[IKE] received retransmit of response with ID 0, but next request already sent
14[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[38829] (1756 bytes)
14[IKE] received retransmit of response with ID 0, but next request already sent
09[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[38829] (76 bytes)
09[ENC] parsed TRANSACTION request 863364433 [ HASH CPRQ(SUBNET SUP) ]
09[ENC] generating TRANSACTION response 863364433 [ HASH CP ]
09[NET] sending packet: from 192.168.178.94[38829] to 1.2.3.4[4500] (76 bytes)
11[NET] received packet: from 1.2.3.4[4500] to 192.168.178.94[38829] (40 bytes)
11[IKE] queueing INFORMATIONAL_V1 request as tasks still active

Re: Using StrongSwan to connect R81.10 GW using xauth-hybrid

PhoneBoy — Thu, 23 Mar 2023 21:51:43 GMT

It's possible you'll need to apply a hotfix.
See: https://support.checkpoint.com/results/sk/sk118536

However, even that suggests IKEv2 will be a better experience.
The documentation clearly mentions IKEv2 and StrongSWAN:

It would be a wise idea to enable "Prefer IKEv2, Support IKEv1" in Global Properties.
This should not impact your existing Remote Access connections to make this change.

Otherwise, I suggest a TAC case: https://help.checkpoint.com