Changing Encryption Domain? Client may not update.

[George_Ellis]

Just passing this on as we just encountered it.

A request came to add some new IPs to the Encryption Domain so that the traffic would go internally instead of to the internet in the split tunnel configuration.  Added new IPs.  Oops, those new IPs are used by other apps, put it back the way it was.

A client logged in to the original settings.  Then the change with the new IPs, and the client logged in.  THEN (last one), the client logged in after the backoff.  The client was still going through the internal path (I spent a bunch of time verifying this with audits, etc.)

Problem?  The client had cached the path.
Easiest Solution?  Delete the site in the VPN client and recreate it.

Or you can delete the trac.config file.  

Like I said, just passing it on.  I did not find a SK referencing it, so I decided to share it here.

[israelfds95]

Could you please explain the issue in a bit more detail? It was a little difficult to understand, but from what I understood, you have a Remote Access configuration with split tunneling enabled, intended to ensure that an application with a public IP does not go out through the internet for VPN clients, but instead is accessed through the application’s private IP via the tunnel.

1 – Show this points:

Re-enter the IPs in the VPN domain and push the policy again.

• Ask the user to disconnect and reconnect.

• Restart the VPN client.

• In some cases, restarting the computer may help.

• Check whether the client’s computer received the new routes using route print in the command prompt.

• Run a tracert to the application from the test user’s machine and verify whether it is going through the tunnel as expected.

• Test with other users.
  
  
  Best Regards

[George_Ellis]

That is not the scenario.  The destination is a AWS address.  They wanted the AWS connection to pass through internal networks so that it could get a corp public NAT.  So they added the IP to the Encryption Domain.  That broke others going to the same address for different apps that relied on the internet connection.  So, removed the IP from the group defining the encryption domain.  That fixed it for many, but a few clients were still trying to go through internal.  It was because the client still had the path defined in the previous config.  Restarting did not change it.  By redoing the site, that cleared it from tracs.config.

[the_rock]

Im so glad you posted about this, because I had the same issue with few clients. I really wish I knew in what scenarios deleting and recreating the site would NOT be needed.

Sadly, that appears to be very difficult to know, so I make sure I always let people know that might be needed, so they are aware beforehand.

[the_rock]

Out of curiousity, though obviously its AI response, but somewhat interesting...

******************

In Check Point Remote Access VPN (Harmony/Endpoint Security VPN / Mobile / SNX), you do NOT need to delete & re‑create the VPN “site” on the client as long as the change you made on the firewall doesn’t invalidate what the client cached when the site was created (gateway address resolution, trust/fingerprint, and authentication method). [sc1.checkpoint.com], [community….kpoint.com], [community….kpoint.com]

Below are the common change types where re-creating the site is not needed—a disconnect/reconnect (or “Update Topology”) is usually enough.

---

✅ Changes that typically DO NOT require deleting/re-creating the client “site”

1) Access Control / Security Policy rule changes

If you’re only changing what remote users can access (new rules, modified services, rule ordering, VPN column changes, etc.), the client site entry doesn’t need to change—you just install policy and users reconnect. [sc1.checkpoint.com]

2) Remote Access community membership / user group changes

Adding/removing gateways in the Remote Access community, changing participating user groups, or changing Identity Awareness / Access Roles that control who gets access are policy-side changes; they do not require rebuilding the site on the endpoint. [sc1.checkpoint.com]

3) Crypto settings adjusted in Global Properties (encryption/integrity/DH)

Changing IKE/IPsec proposal preferences (encryption algorithms, integrity, DH group) is normally handled via policy and negotiation; users typically just reconnect after policy install. [sc1.checkpoint.com]

Practical note: users may need to disconnect/reconnect so Phase 1/2 can renegotiate using the new settings. [sc1.checkpoint.com]

4) Topology/Office Mode parameters where “Update Topology” is sufficient

When you change things like Office Mode behavior, split-tunnel routes, or similar “site topology” data, Check Point’s own guidance is generally to have users create or update site topology after policy install—not necessarily delete/recreate the site entry. [sc1.checkpoint.com]

5) Certificate updates where the trust anchor/fingerprint expectation doesn’t change

The client uses a fingerprint/trust check during site definition/initial connection; if your changes don’t alter what the client expects/trusts (e.g., still anchored the same way), then you typically don’t need to delete/recreate—at most users may see a prompt to verify/accept. [sc1.checkpoint.com]

---

A simple rule of thumb (fast test)

You usually don’t need to delete/recreate the site if all three are true:

1. Same gateway identifier (the hostname/IP the site points to still works) [community….kpoint.com]
2. Same authentication method (you didn’t switch CP password ↔ RADIUS/other) [community….kpoint.com]
3. Trust/fingerprint isn’t “stale” (client isn’t rejecting the gateway identity) [sc1.checkpoint.com]

If those hold, changes like policies, groups, and crypto settings generally don’t require site recreation. [sc1.checkpoint.com]

---

For context: when site recreation is commonly required (so you can avoid it)

Even though you didn’t ask, this helps draw the boundary:

• Switching authentication mechanism (e.g., Check Point password → RADIUS) can require delete/re-add. [community….kpoint.com]
• If the site was added by FQDN, the client may resolve it once; if the gateway IP behind that FQDN changes, you may have to delete/re-add. [community….kpoint.com]

---

Quick troubleshooting before telling users to delete/recreate

Try these in order (least disruptive first):

1. Disconnect/reconnect (forces renegotiation). [sc1.checkpoint.com]
2. Update site topology / refresh site info (if your client UI supports it). [sc1.checkpoint.com]
3. If it’s an FQDN-based site and you suspect IP changed, confirm behavior (some clients cache resolution). [community….kpoint.com]

---

A couple questions so I can answer exactly for your environment

1. Which client are you using: Harmony Endpoint VPN / Endpoint Security VPN / Mobile VPN / SNX?
2. Do users create the site using FQDN (e.g., vpn.company.com) or a raw IP? [community….kpoint.com]
3. What change are you planning (policy rule change, encryption settings, certificate, auth method, gateway IP/FQDN)?

If you tell me those three, I can give you a precise “no client action / reconnect only / update topology / must recreate” answer for your specific change.

[George_Ellis]

It was actually Grok that said it might be the site's cached material and to recreate it or delete the trac file.

I spent about 3 hours going through LDAP groups, validating objects, auditing changes, and every other thing related to how the VPN was talking to the client.  Then to find that the client was stubborn and not listening to what it was told.  😉