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

[RemoteUser]

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?

[Gaurav_Pandya]

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.

[PhoneBoy]

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

[the_rock]

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.

[the_rock]

Hey bro,

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

[RemoteUser]

Hey bro

Split Tunnel

[the_rock]

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

[RemoteUser]

not yet buddy

[the_rock]

If possible, I would definitely test it.

[RemoteUser]

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

[Bob_Zimmerman]

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.

[PhoneBoy]

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. 

[emmap]

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.