Machine certificate based permissions

[i4004]

Hi! At our organization we have permissions to local resources based on machine cert + (login/password + OTP authentication). So i did setup connection like in the #87

I tried with the code from the main branch (94ae42f).

I am connecting like this:

sudo ./target/debug/snx-rs \
  --tunnel-type=ipsec \
  --cert-type=pkcs12 \
  --cert-path="my-pc-cert.pfx" \
  --cert-password='pass' \
  --login-type=vpn_XXX \
  --server-name=serveraddr.com \
  --log-level=debug

The logs:

2026-03-03T15:29:23.979240Z DEBUG snx_rs: >>> Starting snx-rs client version 5.2.0
2026-03-03T15:29:23.979261Z DEBUG snx_rs: Running in standalone mode
2026-03-03T15:29:24.090498Z DEBUG hyper_util::client::legacy::connect::http: connecting to 
2026-03-03T15:29:24.127897Z DEBUG hyper_util::client::legacy::connect::http: connected to 
2026-03-03T15:29:24.290348Z DEBUG snxcore::tunnel::ipsec::natt: Sending NAT-T probe to 
2026-03-03T15:29:24.305467Z DEBUG snxcore::tunnel::ipsec::natt: Received NAT-T reply from : source port: 4500, dest port: 4500, hash: 4ae71336e44bf9bf79d2752e234818a5
2026-03-03T15:29:24.307370Z DEBUG snxcore::platform::linux: Kernel xfrm available: true
2026-03-03T15:29:24.307418Z DEBUG snxcore::tunnel::ipsec::connector: ESP transport: kernel
2026-03-03T15:29:24.409151Z DEBUG isakmp::ikev1::service: Begin SA proposal
2026-03-03T15:29:24.409398Z DEBUG isakmp::transport::tcpt: Connecting to 
2026-03-03T15:29:24.417880Z DEBUG isakmp::transport::tcpt: Connected, starting TCPT handshake
2026-03-03T15:29:24.437563Z DEBUG isakmp::ikev1::service: Negotiated SA hash algorithm: Sha256
2026-03-03T15:29:24.437601Z DEBUG isakmp::ikev1::service: Negotiated SA encryption algorithm: AesCbc
2026-03-03T15:29:24.437606Z DEBUG isakmp::ikev1::service: Negotiated SA key length: 32
2026-03-03T15:29:24.437610Z DEBUG isakmp::ikev1::service: Negotiated SA group: Oakley14
2026-03-03T15:29:24.437617Z DEBUG isakmp::ikev1::service: Negotiated SA lifetime: 28800
2026-03-03T15:29:24.437902Z DEBUG isakmp::ikev1::service: End SA proposal
2026-03-03T15:29:24.437909Z DEBUG isakmp::ikev1::service: Begin key exchange
2026-03-03T15:29:24.454111Z DEBUG isakmp::ikev1::service: End key exchange
2026-03-03T15:29:24.454631Z DEBUG snxcore::tunnel::ipsec::connector: Machine name: Some("my cert here")
2026-03-03T15:29:24.455028Z DEBUG isakmp::ikev1::service: Begin identity protection
2026-03-03T15:29:24.455091Z DEBUG isakmp::ikev1::service: Using hybrid authentication with machine certificate
2026-03-03T15:29:24.481707Z DEBUG isakmp::ikev1::service: Trusted server fingerprint: 
2026-03-03T15:29:24.481866Z DEBUG isakmp::ikev1::service: Fingerprint for: organizationName = "",commonName = " VPN Certificate": 
2026-03-03T15:29:24.481883Z DEBUG isakmp::ikev1::service: Internal IPSec certificate validation succeeded
2026-03-03T15:29:24.481893Z DEBUG isakmp::ikev1::service: IP address from ID payload: 
2026-03-03T15:29:24.481979Z DEBUG isakmp::ikev1::service: ID payload signature verification succeeded!
2026-03-03T15:29:24.481983Z DEBUG isakmp::ikev1::service: Awaiting authentication factors
2026-03-03T15:29:24.984673Z DEBUG isakmp::ikev1::service: Attributes message ID: 3969f060
2026-03-03T15:29:24.984720Z DEBUG isakmp::ikev1::service: End identity protection
2026-03-03T15:29:24.984744Z DEBUG snxcore::tunnel::ipsec::connector: No status in reply, requested challenge for: UserPassword
2026-03-03T15:29:24.984776Z DEBUG snxcore::tunnel::ipsec::connector: Challenge msg: 
2026-03-03T15:29:24.985063Z DEBUG snxcore::tunnel::ipsec::connector: Challenge ID: CPSC_SP_URL
2026-03-03T15:29:24.985069Z DEBUG snxcore::tunnel::ipsec::connector: Challenge prompt: 
For identity provider authentication, open the following URL in your browser:

2026-03-03T15:30:11.492579Z DEBUG snxcore::otp: Successfully received OTP from the browser
2026-03-03T15:30:11.492741Z DEBUG isakmp::ikev1::service: Sending auth attribute: UserPassword, timeout: Some(120) seconds
2026-03-03T15:30:11.506936Z DEBUG isakmp::ikev1::service: Message ID: 3969f060
2026-03-03T15:30:11.506973Z DEBUG isakmp::ikev1::service: Response message ID: 3969f060
2026-03-03T15:30:11.506990Z DEBUG snxcore::tunnel::ipsec::connector: IPSec authentication succeeded
2026-03-03T15:30:11.507000Z DEBUG isakmp::ikev1::service: Sending ACK response
2026-03-03T15:30:11.507505Z DEBUG snxcore::tunnel::ipsec::connector: Authenticated username: username
2026-03-03T15:30:11.507550Z DEBUG snxcore::tunnel::ipsec::connector: Using dummy MAC address: 7b3637313833
2026-03-03T15:30:11.507564Z DEBUG isakmp::ikev1::service: Begin sending OM request
2026-03-03T15:30:11.723222Z DEBUG isakmp::ikev1::service: End sending OM request
2026-03-03T15:30:11.723331Z DEBUG snxcore::tunnel::ipsec::connector: OM IP address: 
2026-03-03T15:30:11.723348Z DEBUG snxcore::tunnel::ipsec::connector: OM IP netmask: 255.255.248.0
2026-03-03T15:30:11.723361Z DEBUG snxcore::tunnel::ipsec::connector: OM IP lifetime: 240000 seconds
2026-03-03T15:30:11.723370Z DEBUG snxcore::tunnel::ipsec::connector: OM DNS servers: 
2026-03-03T15:30:11.723384Z DEBUG snxcore::tunnel::ipsec::connector: OM search domains: 
2026-03-03T15:30:11.723413Z DEBUG isakmp::ikev1::service: Begin ESP SA proposal
2026-03-03T15:30:11.749513Z DEBUG isakmp::ikev1::service: Negotiated transform id: EspAesCbc
2026-03-03T15:30:11.749579Z DEBUG isakmp::ikev1::service: Negotiated ESP auth algorithm: HmacSha256
2026-03-03T15:30:11.749585Z DEBUG isakmp::ikev1::service: Negotiated ESP key length: 32
2026-03-03T15:30:11.749683Z DEBUG isakmp::ikev1::service: End ESP SA proposal
2026-03-03T15:30:11.749697Z DEBUG snxcore::tunnel::ipsec::connector: ESP lifetime: 3600 seconds
2026-03-03T15:30:11.870280Z DEBUG hyper_util::client::legacy::connect::http: connecting to 
2026-03-03T15:30:11.881197Z DEBUG hyper_util::client::legacy::connect::http: connected to 
2026-03-03T15:30:12.064340Z DEBUG snxcore::tunnel::ipsec::imp::native: Resolved gateway address: , acquired internal address: 
2026-03-03T15:30:12.068368Z DEBUG snxcore::platform::linux::xfrm: Source IP: 
2026-03-03T15:30:12.068380Z DEBUG snxcore::platform::linux::xfrm: Target IP: 
2026-03-03T15:30:12.129553Z DEBUG snxcore::tunnel::ipsec::imp::native: Running IPSec tunnel
2026-03-03T15:30:12.129574Z DEBUG snxcore::tunnel::ipsec::natt: Listening for NAT-T packets on port 0.0.0.0:57740
2026-03-03T15:30:12.129634Z DEBUG snxcore::platform::linux::routing: Setting up keepalive route through snx-xfrm
2026-03-03T15:30:12.131515Z DEBUG snxcore::platform::linux::net: NetworkManager state changed to ConnectedGlobal

2026-03-03T15:30:12.256281Z DEBUG snxcore::tunnel::ipsec::imp::native: Configuring resolver: 
2026-03-03T15:30:12.256323Z DEBUG snxcore::platform::linux::resolver: Detected resolver: SystemdResolved
2026-03-03T15:30:12.275396Z DEBUG snxcore::tunnel::ipsec::connector: Tunnel connected
   Connected since: 2026-03-03 20:30:12
       Server name: servername.com
         User name: userbame
        Login type: vpn_XXX
       Tunnel type: IPSec
    Transport type: UDP XFRM
        IP address: 
       DNS servers: 
    Search domains: 
         Interface: snx-xfrm
    DNS configured: true
Routing configured: true
     Default route: false
Tunnel connected, press Ctrl-C to exit.

The connection was establishing successfully (like it was before without cert), and general VPN works fine. but still the permissions based on the cert does not work.

To get the permissions working on the server side it should look like this (like using checkpoint windows client):

But i got this:

Do we need to pass the cert somewhere else maybe?

As i understand the windows official client have some logic to find the machine cert in the "Local Computer -> Personal" certificate store and pass it to the gateway somehow.

[ancwrd1]

Could you try with --client-mode=endpoint_security parameter and see if it makes a difference?

[arminfelder]

I just compared the logs on my setup, and for me there is not much difference, but this is only the mobile access blade(see below).

then I activate Identity Awareness blade, but for snx-rs I get no log entry at all, and for checkpoint endpoint security client I see more or less the same as you do.

smartconsole:
cp_client.log
snx-rs.log

trace logs from $FWDIR/log (vpn debug ikeon + vpn debug trunc)

checkpoint endpoint security cp.tar.gz
checkpoint endpoint security(identity awareness blade active) cp-identiyaware.tar.gz
snx-rs snx-rs.tar.gz

snx-rs.conf:

user-name=usertest
password=Q1phNG1YTVk=
cert-type=pkcs12
cert-path=/home/armin/CLionProjects/checkpoint/certs/machine.pfx
cert-password=123
client-mode=endpoint_security
server-name=192.168.110.40
login-type=vpn
no-routing=true
tunnel-type=ipsec
ca-cert=/home/armin/CLionProjects/checkpoint/certs/gw-9ae775-vpn-certificate-chain.pem
ignore-server-cert=true

[ancwrd1]

I think the only real difference in the IKE exchange is in the authentication blob.

This is what Windows client sends:

	:clientType (TRAC)
	:oldSessionId ()
	:protocolVersion (100)
	:client_mode (endpoint_security)
	:selected_realm_id (vpn)
	:secondary_realm_hash (c4ca4238a0b923820dcc509a6f75849b)
	:client_logging_data (
		:device_id ("{61BA9F44-A6FD-4D67-BFF3-460E9FAC6473}")
		:client_name ("Endpoint Security VPN")
		:client_ver (E88.30)
		:client_build_number (986105506)
		:device_type (PC)
		:os_name (Windows)
		:os_version (11)
		:os_edition (Professional)
		:os_service_pack ()
		:os_build (26200)
		:os_bits (64bit)
		:machine_domain (corp.example.local)
		:machine_name (DESKTOP-AIFEKR7)
		:physical_ip (192.168.110.196)
		:mac_address ("52:54:00:c0:d2:18,54:df:1c:a3:a8:0a")
	)

This is what snx-rs sends:

        :clientType (TRAC)
        :oldSessionId ()
        :protocolVersion (100)
        :client_mode (endpoint_security)
        :selected_realm_id (vpn))
        :secondary_realm_hash (45c48cce2e2d7fbdea1afc51c7c6ad26)
        :client_logging_data (
                :device_id ("{2B43E629-F253-59E3-992F-0D6FEDB64A3B}")
                :machine_name (DESKTOP-AIFEKR7))
                :os_name (Windows))

Some fields are missing, may be they do actually matter for that identity awareness, not sure. We can perhaps try to play with them here:

snx-rs/crates/snxcore/src/tunnel/ipsec/connector.rs

Line 655 in 94ae42f

let realm = AuthenticationRealm {

I will also check the logs, @arminfelder thanks a lot for your help!

[arminfelder]

I checked my config and of course I missconfigured the identity awareness,
after checking "Remote Access" in "Identity Awareness",
I get the same result with snx-rs, as with checkpoint endpoint security vpn client

[ancwrd1]

I see in the logs you used the default client mode "secure_connect" instead of "endpoint_security", but it seems it does not matter that much in your case. Still, some other fields in the client_logging_data may be significant, in particular I suspect the "machine_domain", "physical_ip" and may be also "client_name".

[arminfelder]

here are my smartconsole logs,

checkpoint endpoint security VPN pdp-cp.log
snx-rs pdp-snx-rs.txt

[i4004]

Tested with --client-mode=endpoint_security, same result.

[ancwrd1]

I think it's most likely a matter of custom client_logging_data structure (see above comments).
I have added now an additional parameter to the application, --client-logging-data=/path/to/client_logging_data.json.

Please create a JSON file and fill in your specific details in there:

{
    "client_name": "Endpoint Security VPN",
    "client_ver": "E88.30",
    "client_build_number": "986105506",
    "device_type": "PC",
    "machine_domain": "corp.example.local",
    "machine_name": "DESKTOP-XXX",
    "physical_ip": "192.168.110.196"
}

I think the important ones are machine_name and machine_domain, but may be also physical_ip. The machine_name should match the one from the certificate and from the Windows host, and machine_domain should be the domain which Windows PC is joined.

Then specify this file in the --client-logging-data parameter.