topic Re: Check Point VPN route with low metric overriding more specific route from another tunnel in General Topics

Check Point VPN route with low metric overriding more specific route from another tunnel

RemoteUser — Fri, 09 Jan 2026 08:09:33 GMT

Hi Mates!!

I'm experiencing a routing issue when both the Check Point VPN client and another third-party VPN tunnel are active at the same time.

The Check Point VPN pushes a broad route (e.g., a /15 network) with metric 1, while the other tunnel adds a more specific route for a single IP with a higher metric.

As a result, traffic to that specific IP follows the Check Point route instead of the more specific one and gets lost.

Is there a way to configure the Check Point client (or gateway) so that the routes it pushes have a higher metric, preventing them from overriding more specific routes added by other adapters/tunnels?

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

Gaurav_Pandya — Fri, 09 Jan 2026 12:14:35 GMT

I recommend focusing on pushing only the required routes from Check Point rather than relying on routing preferences. You can achieve this by adding the specific network (for example, a /24 subnet) to the Remote Access VPN encryption domain group. This ensures that only the intended routes are pushed, which should resolve the issue.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

PhoneBoy — Fri, 09 Jan 2026 19:40:51 GMT

Does not appear you can choose a metric for the route injected by the VPN client.
This would be an RFE.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

the_rock — Fri, 09 Jan 2026 19:44:36 GMT

Good question bro. I would assume unless there is option to change it somewhere from the web UI, not sure it can be done otherwise. You can ask TAC, but sounds like what Phoneboy said about it being an RFE would make sense.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

the_rock — Sat, 10 Jan 2026 03:17:06 GMT

Hey bro,

Just curious...is this split or full tunnel?

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

RemoteUser — Sat, 10 Jan 2026 10:08:52 GMT

Hey bro

Split Tunnel

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

RemoteUser — Sat, 10 Jan 2026 10:14:59 GMT

Just checked and with the "route -n" you can see the metric, but not on the vpngw this is annoying.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

the_rock — Sat, 10 Jan 2026 12:29:08 GMT

Does it make any difference with the full tunnel or have not tried that yet?

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

RemoteUser — Mon, 12 Jan 2026 11:07:26 GMT

not yet buddy

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

the_rock — Mon, 12 Jan 2026 12:25:01 GMT

If possible, I would definitely test it.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

Bob_Zimmerman — Mon, 12 Jan 2026 15:07:13 GMT

The metric is only used to decide between two routes for the same block. A more specific route should always be picked over a less specific route, and changing the metric won't affect this.

It sounds like something else is going on here.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

PhoneBoy — Mon, 12 Jan 2026 16:06:44 GMT

It may be like it is on the gateway side where VPN routing happens at the kernel (driver) level.
Which means it doesn't matter what the metric on the client is.

Re: Check Point VPN route with low metric overriding more specific route from another tunnel

emmap — Tue, 13 Jan 2026 04:02:42 GMT

If this is endpoint VPN then probably we and the other VPN provider will tell you that having two VPN clients on the same machine isn't supported and is a potential security risk.

Otherwise yea it'll be an RFE to get that metric to be configurable. It may be cosmetic though, in that our VPN driver in the kernel picks up the connection before it even reaches the OS routing table. I don't know enough about how it works that deeply in there, but that would explain why the more specific route doesn't take precedent.