- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Unnumbered VTI to 3rd party gateway
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unnumbered VTI to 3rd party gateway
Hey Everyone I created a technical whitepaper on how to connect and send all traffic through an unnumbered virtual tunnel interface (VTI)
- Labels:
-
Integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you elaborate on configuration of the unnumbered interfaces for a cluster? This part was missing from the PDF. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Check my, and other people's, earlier messages about this:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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