Unstable Connection

[macchie]

Good morning, first, thanks for your valuable work on this unofficial Client. Sadly, even if the connection is starting and the log is not giving any weird error the connection seems to drop after a random about of seconds (usually between 30-60s).

Im using the latest version (tried both compiled and downloaded from Release page) but i got the same result.

Im connecting to a Client network and sadly im missing the server version yet.

This is the command i use:

$ snx-rs --mode standalone \
  --ignore-server-cert true \
  --no-cert-check true \
  --server-name $SERVER_ADDRESS \
  --client-cert $CERT_PATH \
  --cert-password $CERT_PASS \
  --login-type vpn \
  --no-keychain true \
  --tunnel-type ssl \
  --log-level debug

I tried using IPSec but im getting an error, i attached both logs for a regular run that drops after 30s and the ipsec error.

snx-rs.log snx-rs-ipsec.log

Any hint or idea? I think SSL Tunnel is failing but i cant switch to ipsec for testing.

Currently on:

Distributor ID: Zorin
Description:    Zorin OS 16.3
Release:    16
Codename:   focal

Thanks a lot

[ancwrd1]

I see that you are using version 1.0.0-rc3. May be try the latest 1.0.0 (released), there were many bugfixes.

[macchie]

Oh gosh, i planned to post the issue yesterday, didnt notice the new release. Will test now, thanks.

[macchie]

I did test with your release and by compiling the project myself (v1.0.0) and im getting the same result sadly, the log stopped at "Tunnel connected" without further errors, the connection was alive for 60s more or less. Seems like the tunnel is dead in the background. Im not that proficient in Rust to help you out, sorry. :(

[ancwrd1]

The tunnel is supposed to be 'keepalived' by the interval which is contained in the received hello reply message. I've added now a couple of additional trace-level logs, perhaps you could run it with 'trace' log level and check the HelloReplyData structure, in particular the timeouts, which should show something like: timeouts: Timeouts { authentication: 86392, keepalive: 20 }.

Also you should see the KeepaliveRequestData in the logs with the specified period.

As for the IPSec, the attached log just contains the same SSL tunnel logging :)

[macchie]

Im sorry i just noticed the second file is wrong, ill run the new version in a minute and attach the correct file for ipsec.

[macchie]

I did run with trace, ipsec log added. SSL tunnel got stuck at 10:44:04 in the log, i was pinging a VPN address and took note of it.

ipsec.log ssl.log

I did obfuscate the addresses, guess its not an issue.

[ancwrd1]

So for IPSec your gateway doesn't seem to support SHA2-256 authentication algorithm, only supports SHA1. I can perhaps have a look at it when I have time. Right now snx-rs only supports SHA2-256. For SSL tunnel, I made some changes around keepalive packets, could you try it from the latest main branch?

[macchie]

Still getting stuck at around 60secs, here is the latest log, sorry to make you struggle :(

ssl.log

[ancwrd1]

I don't know, to be honest, it looks ok in the code and in the logs. Does the official Linux application work for you?

[macchie]

I don't know, to be honest, it looks ok in the code and in the logs. Does the official Linux application work for you?

Sadly it stopped working lately, i suspect due to an update on the VPN server side, everything looks good to me as well in the logs etc... maybe its them closing the connection on us but im not sure. Thanks for your time, ill try and make it work, if i come up to something ill let your know and maybe open a PR.

Thanks!

[ancwrd1]

I have added support for weaker IPSec algorithms, at least for initial IKE SA exchange (key exchange).

You could try it and see if it brings you any further. ESP protection (the actual data encryption) remains at AES-CBC-256 and SHA-256. I can't test the weaker algorithms there because my VPN server doesn't accept them.

[macchie]

Thanks again for your commitment, here is the log while using ipsec as tunell.

[ancwrd1]

Ok try now, I have changed something.

[macchie]

Now it asked me for a username, unsure about this, i used the CN from my cert. Anyway after adding --user-name flag i got this:

[ancwrd1]

Ah, you are using certificate login, right? Unfortunately this is not supported yet for IPSec tunnel.

[macchie]

Ah, you are using certificate login, right? Unfortunately this is not supported yet for IPSec tunnel.

Looks like im the unluckiest guy ever so far :D I saw on some forum people referring to StrongSwan client that should be compatible from some R81 version and above (of the server), but i dont think ill even try to setup that...

We are seriously considering building a macOS / Windows machine and setup routing on it.. sadly i have no access to the server config but i suppose it is very badly configured.

Also had to disable any kind of certificate check because they use self-signed https certificates and i get errors everywhere without skipping.

Not sure why things work for a while on ssl and then everything drops.. but it may be the server at this point. Hope they will provide me with some informations about version in the next days.

[ancwrd1]

It's not hard to add certificate login for IPSec, I'll probably do it anyway, but I can't really test it because I have no access to Checkpoint server with cert login types.

[macchie]

That would be awesome, you are very kind. Ill try and provide any log i can get that might be helpful!

[ancwrd1]

I have added ipsec-certs branch with some (still experimental) support for certificate login in IPSec tunnel. Please try and check how far would you go with it.

[macchie]

I'll do another round of testing tomorrow, again, can't thank you enough 🙏

[macchie]

Sorry i wasn't able to test yesterday, here is the log from the ipsec-certs branch!

[ancwrd1]

Almost there :) The weaker ESP algorithms (AES-128 probably) should be supported as well.

[ancwrd1]

I have added weaker keys support, please try again. Unfortunately, as I said, I can't really test it, so it's a bit shooting in the dark. Anyway worth giving it a try.

[macchie]

Aaaaand... the nightmare continues :(

[ancwrd1]

Yeah looks like some parameter is missing or incorrect but it's impossible to tell which exactly. I have added a small change now but I don't think it will help. I guess it's not possible to pull the logs from the server? ESP proposal consists of encryption type (AES-CBC), key length (128, 256), auth algorithm (hmac-sha, hmac-sha256), some ID payloads (IP address and netmask acquired from the gateway) and the lifetime parameter. Any of those can be rejected by the server.

[macchie]

Getting the same error, ill try and retrieve more info from the VPN provider :(

[macchie]

I was actually able to collect logs from the Checkpoint VPN Client for MacOS, there is a bunch of informations in the output, maybe something inside her could help?

Here is some data i found about the auth fase:

[ 39658 0x114423dc0][14 Mar 12:20:55][TR_AUTH_MANAGER] TrAuthenticationManager::AbortAuthRequest: __start__ 12:20:55
[ 39658 0x114423dc0][14 Mar 12:20:55][TR_AUTH_MANAGER] TrCredKey::TrCredKey: creating credKey
[ 39658 0x114423dc0][14 Mar 12:20:55][TR_AUTH_MANAGER] TrAuthCache::GetSiteAuthReq: entering - item (gw = vpn.pac2000a.it, authMethod=p12-certificate, realmId=vpn)
[ 39658 0x114423dc0][14 Mar 12:20:55][TR_AUTH_MANAGER] TR_AUTH_MANAGER::TrAuthenticationManager::AbortAuthRequest: Failed to find request to abort, (gw = vpn.pac2000a.it, authMethod=p12-certificate, realmId=vpn)
[ 39658 0x114423dc0][14 Mar 12:20:55][TR_AUTH_MANAGER] TrAuthenticationManager::AbortAuthRequest: __end__ 12:20:55 Total time - 0 seconds
[ 39658 0x114423dc0][14 Mar 12:20:55][TR_FLOW_STEP] TR_FLOW_STEP::TrConnEngineConnectStep::Cancel: Sending disconnect to GW
[ 39658 0x114423dc0][14 Mar 12:20:55][tunnel] IkeV1Tunnel::cancel_connect: started
[ 39658 0x114423dc0][14 Mar 12:20:55][tunnel] IkeV1Tunnel::notifyGwSADeletion: started
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] **** create_informational: Create Informational packet
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] SetIVMaterial: IV material was already set . exiting
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] ike_hash_method_to_alg: hash method is 2 = SHA1
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] compute_IV: using IV metarial
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 40 e6 3c e0 82 ef 15 04 14 4b 28 6f 2f b3 3e 75 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 54 08 80 12 2d 86 f5 b6 78 b8 95 cd 6e 9e d7 cc 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 6b 94 ca a1 39 73 2e 70 c4 75 8f c1 9d 02 4f af 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 2e 77 82 56 02 09 4c 39 28 97 fe 2e 36 76 19 54 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] ike_hash_method_to_alg: hash method is 2 = SHA1
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 2e 77 82 56 02 09 4c 39 28 97 fe 2e 36 76 19 54 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 09 7e ee 7d 51 31 ae 95 bd 14 ba 99 b0 43 4b b0 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 00 0f 34 4e 0a b3 34 97 ef 95 44 c7 31 25 1e 55 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE] 54 08 80 12 2d 86 f5 b6 78 b8 95 cd 6e 9e d7 cc 
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE_SEC_ASSOC] IkeSecAssoc::Encrypt :- start encrypting packet
[ 39658 0x114423dc0][14 Mar 12:20:55][IKE_SEC_ASSOC] IkeSecAssoc::Encrypt :length=56
[ 39658 0x114423dc0][14 Mar 12:20:55][transport] AutoDetect_Transport::IkeT_PacketSend: start...

[ancwrd1]

The initial IKE Phase1 exchange (Main Mode or MM) is not a problem, it works fine. It establishes the security association (SA) between peers. The issue is the Phase2 (Quick mode or QM), where the ESP key proposal is sent to the gateway (ESP keys are used to actually encrypt traffic). That's where we get "User not correctly configured" error back, meaning that one of the following parameters is not accepted:

• Auth algorithm: HmacSha256 or HmacSha1
• Encryption algorithm: AES-CBC
• Key size: 256 or 128
• ESP lifetime: 3600 seconds
• Encapsulation type: ESPInUDP

May be it can be seen somewhere down in the logs. You could try also this project: https://gitlab.com/cpvpn/cpyvpn (ipsec branch) It's written in Python, let me know if you could get connected with it. Set the env variable MSG_DBG=1 before running it, to get debug output.

[macchie]

Here is the complete log file, its quite messed up as i said, ill try with cpyvpn meanwhile, thanks.

trac.log

[ancwrd1]

Don't think I can pull anything useful from it, after a quick look. Unfortunately their client doesn't log encryption keys so it's not possible to decrypt the captured IKE exchange (e.g. via Wireshark).

I had a similar error before with the server I use, which was fixed by using a different hash algorithm ID in the ESP SA request. However, now it sends 4 of them, and it doesn't work with your VPN gateway. Anyway, if cpyvpn works, I might have an idea what's wrong.

[ancwrd1]

I have now added AES-192 as well (just in case it is really a required key length). Also changed one flag (domain of interpretation), you could may be check if it improves something. It's all in main branch now.

[macchie]

Still nothing with latest changes, we submitted the logs to Checkpoint directly via our Client and we are now waiting for informations from them. Thanks again so far.

[ancwrd1]

Latest version 2.2.4 has 3DES encryption added, I think it might fix the problem with IPSec tunnel.