Mixing Universal Tunnel and specific topologies

[stallwoodj]

Hi,

We have an inherited Juniper firewall which we are planning to migrate to Check Point. 

Some of the tunnels that are established have a local traffic selector of 192.168.x.0/24 and a remote selector 0.0.0.0/0. And one has them the other way round with a local domain 0/0 and a remote domain 172.x.x.0/24

I've tried the standard route-based VPN method (in R81.10 lab back-to-back with an SRX), having set the default VPN topology as an empty group, creating VTIs and static routes, and overriding the local or remote topology to specific subnet on a per-VPN basis.

The SRX happily comes up and negotiates its IKEv2 with an initial traffic selector <0.0.0.0/0>-<192.168.x.0/24>, great. However, as soon as I attempt to push traffic, the Check Point tries negotiate a new child SA with <0.0.0.0/0>-<0.0.0.0/0> which the SRX rejects "Traffic selectors unacceptable". The attempt was seen in iked.elg and the traffic captured in legacy_ikev2.xmll.

I tried to override this with subnet_for_range_and_peer but it had no affect on the issue.

So, is it / will it ever be possible to use route-based VPN without being forced to use Universal Tunnel at both ends? Currently I'm forced to get the 3rd party peers to change their traffic selectors which is annoying 🙂

Thanks

Jamie

[PhoneBoy]

What's the setting in the VPN Community?
One Tunnel per Community would result in the 0.0.0.0/0 selector.

[stallwoodj]

Hi Dameon,

I set one per subnet pair, which caused it to send two traffic selector pairs, host-to-host with protocol ICMP, and universal. Exactly the behaviour I saw with per-Gateway pair.

[PhoneBoy · Accepted solution]

I'm trying to find something other than this community thread that confirms this is expected behavior: https://community.checkpoint.com/t5/General-Topics/Route-based-VPN-Proxy-ID-0-0-0-0-0/m-p/55192#M110... 
Maybe you can change this with the "Before R77.20" version of Option 1 here: https://support.checkpoint.com/results/sk/sk108600
Otherwise, I suspect this is an RFE.

[stallwoodj]

Thanks, I've raised the RFE!