Unnumbered VTI to 3rd party gateway

[mbennett1]

Hey Everyone I created a technical whitepaper on how to connect and send all traffic through an unnumbered virtual tunnel interface (VTI) 

[the_rock]

Correct me if Im wrong when I say this, but I always set up route based VPN (in this case either with numbered or un-numbered VTI) with empty enc domain for BOTH CP gateway and 3rd party and it always works.

[Bob_Zimmerman]

You only actually need one of them to be empty. The purpose of the empty group for the encryption domain is to break the domain-based logic for flagging "interesting" traffic. That logic says if the source is in my encryption domain and the destination is in a peer's encryption domain, flag the connection for encryption to that peer. This matching is done before any NAT can be performed. By setting one encryption domain to an empty group, either the source isn't in yours, or the destination isn't in the peer's.

That leaves the traffic free to route "out" the VTI, which is what triggers encryption with a route-based VPN.

The encryption domains are also used for a sort of anti spoofing. If you've ever seen "According to the policy, the packet should not have been decrypted", that means the packet was decrypted from a particular peer, but either the source was not in that peer's encryption domain or the destination was not in your encryption domain. Similarly, "Received a cleartext packet inside an encrypted connection" means the packet was received in the clear, but the source is in some other firewall's encryption domain and the destination is in yours, so it should have come over a VPN between those peers. Route-based VPNs' use of an empty group for one or both of the encryption domains means you should never see either of these, though you may still see normal antispoofing drops.

[the_rock]

@Bob_Zimmerman ...we tried to make it work that way many times and even TAC could not figure it out, so we finally opted for empty groups on both ends and never had an issue. 

[Bob_Zimmerman]

Weird. I've set up route-based VPNs with an empty group on only one peer in at least 30 different management domains. It definitely works in general. I wonder what was wrong.

[the_rock]

We even worked with escalations team and could not get it working on 3 different tunnels. But as soon as we did empty group on both sides, we never had an issue.

[Tobias_Moritz]

@mbennett1 Is there any reason why you defined 3rd party peer object as "external managed checkpoint gateway" instead of just "interoperabel device"? You even named it "cisco", so I guess it was no CP box 🙂

[Duane_Toler]

Can you elaborate on configuration of the unnumbered interfaces for a cluster?  This part was missing from the PDF.  Thanks!

[Leader_Kiongi]

Hello,

Does the physical interface need to be an external interface or any other cluster interface is fine ? I'm struggling to try to make it work with one empty ecryption domain (the remote one) but no luck so far.

Thanks in advance.

Regards,

Alain IKULA

[Duane_Toler]

Check my, and other people's, earlier messages about this:

https://community.checkpoint.com/t5/Security-Gateways/ClusterXL-VTI-with-interface-bond-and-VLAN/m-p...

https://community.checkpoint.com/t5/Security-Gateways/VPN-redundancy-site-to-site/m-p/160504

Summary: IKEv2 only, don't have conflicting VPN domains for route-based and domain-based groups, don't do "encrypt all traffic" on the community, use "VPN directional match" in the policies, use loopback interfaces if you have a cluster and need BGP.

Let us know if you still need more help.  This one can be difficult to configure in the "correct" ways, if you have a complex scenario.

[the_rock]

It can be any, I did it with clients many times using clustered ones without an issue. If it fails, then we need to see why...is it phase 1, phase 2, what packet?

[Leader_Kiongi]

Hello @the_rock  and @Duane_Toler ,

Thank you very much for your feedback. Here are the details of my config and symptoms:

After I configured the star community with my Check Point cluster as central gateway and the remote Fortigate as satellite gateway (the configuration is quite standard, I have tens of tunnels in this management).
The local encryption domain is configured 'According to the gateway' and the remote encryption domain is empty (we cannot configure empty local encryption domain for now as this overrides encryption domains in other communities, as explianed in sk170857)

add vpn tunnel 98 type unnumbered peer India_VPN_Gateway_NTT dev eth1-01

eth1-01 is the external interface of the cluster

Then in SmartConsole I did 'Get Interfaces Without Topology'. I configured the cluster VIP to match the one of the interface eth1-01. The topology is configured according to mbennett1's document above.

Then I add a static route to route the remote network via the tunnel interface:

set static-route 10.144.22.16/29 nexthop gateway logical vpnt98 on

The tunnel is up in SmartView Monitor (see enclosed)

When I initiate a ping to one of the remote IP addresses, I get a timeout. In the logs in SmartConsole, I see the packet being encrypted in the community by the local gateway and then I get a reject with IKE failure and 'no response from peer).

Do you have an idea what could be the issue ? 

Thank you very much in advance for your help

[sekarkarthi]

Nice document! It would have been 100% if you have included how the vpnt1 tunnel interface looks in GW's topology and how to define a security policy for this traffic.

The vpnt1 tunnel interface will take the IP from the Outgoing interface (usually Public IP) on external internet facing interface.

If you External Interface is 1.2.3.0/29 (FW1: 1.2.3.2/29, FW2: 1.2.3.2/29, Cluster IP: 1.2.3.3/29)

The vpnt1 interface will automatically pick the IP (FW1 vpnt1: 1.2.3.2/32, FW2 vpnt1: 1.2.3.3/32). You have to manually edit & define the Cluster IP: 1.2.3.3/32. Note the change in subnet mask for vpnt1 interface. 

This will also do a NAT to make sure the vpn traffic always initiates from CusterIP to the other peer. 

In the Security Policy, it is simple rule. NO need to add the Community that we created in the VPN column. 

Just SRC, DST, SERVICE, ACCEPT, LOG. 

[the_rock]

Hey @sekarkarthi , I think you are confusing something else here. There is absolutely no need to modify anything on external interface when VTIs are configured. You set them up in web UI, updated topology and its all there. We built many route based tunnels to Azure for customers and we NEVER had to do any modifications on any other interfaces and all worked fine.

Regards,

Andy