Route-based VPN with 3rd Party - static routing

[Raj_Khatri]

We currently have a site-to-site VPN with a 3rd party using a route-based VPN.  The 3rd party has a new infrastructure that we need to migrate to but need proper testing before cutover.  A VPN tunnel has been setup and up on the new infrastructure. 

We have a 2 test nodes that are part of the same remote network but traffic is going over the main VPN tunnel.  How can we force the /32 to take the new VPN tunnel as traffic is still going via the production tunnel?

STATIC ROUTES
10.100.1.0/24 GW vpnt1
10.100.1.50/32 GW vpnt2
10.100.1.51/32 GW vpnt2

[AaronCP]

It sounds like you could be hitting a supernetting issue. Even though you've specified the two/32 hosts to use a separate VTI, Check Point is supernetting the traffic to the larger /24 network, and using the original VTI.

Take a look at SK108600 - Scenario 1. It details how to disable supernetting per VPN community from R80.20, as well as how to define subnets for a specific peer gateway in the user.def file.

If that doesn't help, could you NAT those two hosts and attached the NATd address to the VTI?

[Bob_Zimmerman]

It shouldn't be a supernetting thing. That only affects the IDs in the phase 2 negotiation, and route-based VPNs on Check Point always negotiate 0.0.0.0/0 for both sides.

With working VTIs, the static routes as described in the original post should work exactly as desired. This makes me think the tunnel to the new endpoint isn't working, or the tunnel to the old endpoint isn't actually using the VTI.