Route Based VPN

[Ankur_Datta1]

Hi All, 

I facing issue while understanding route based vpn with cisco device. I tried to lab the scenario but its not working. the topology is as follows.

R1--> Checkpoint firewall --> R2

R1 loopback - 1.1.1.1/32

R2 loopback - 2.2.2.2/32

the objective is to ping 1.1.1.1 to 2.2.2.2 and traffic should go through tunnel.

So i am creating route based vpn between checkpoint and r2. The steps that i performed on checkpoint firewall:

1. created a tunnel interface

 remote peer: 192.168.229.10

used numbered

local address 12.12.12.1

remote address 12.12.12.2

2. add route for 2.2.2.2

2.2.2.2 ----> vpn tunnel int (next HOP)

3. on checkpoint gateway in VPN domain call 1.1.1.1. is it necessary to mention VPN domain in route based VPN or we can select or subnets behind gateway option.

4. add inter-operable device - R2.

5. in VPN community used mesh --> added gateway and router, configured phase 1 and phase 2 parameters and added shared secret key.

now on Cisco router i configured following.

R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#hash sha256

R1(config-isakmp)#crypto isakmp key admin@123 address 192.168.229.11

R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET esp-3des esp-sha256-hmac
R1(cfg-crypto-trans)#mode tunnel

R1(config)#crypto ipsec profile IPSEC_PROFILE
R1(ipsec-profile)#set transform-set MY_TRANSFORM_SET

R1(config)#interface Tunnel 0
R1(config-if)#ip address 12.12.12.1 255.255.255.0
R1(config-if)#tunnel source 192.168.229.10
R1(config-if)#tunnel destination 192.168.229.11

R1(config-if)#tunnel protection ipsec profile IPSEC_PROFILE

R1(config)#ip route 1.1.1.1 255.255.255.255 Tunnel0

do we need to mention proxy-acl on cisco router as well. 

As i understand it is not necessary and routing decision will be taken in account instead of policy.

Correct me if i am wrong somewhere. I am still a learner.

THANKS

[PhoneBoy]

As far as I remember, you use an empty encryption domain for route-based VPNs.

See: Configuring route-based VPN 

[Don_Paterson]

Definitely need the empty simple group object in the domains (to let the routing decision force the traffic into the VTI (VPN Tunnelling Interface) and routes to the peer GW VTI interface for the interesting networks on the other side.

I have not tried or seen Route-based VPNs for some time now (since SPLAT (and the old vpn shell command shell)) but did try with interoperable back then, with ASA and also Netscreen SG and I could not get traffic to flow.

I think the SAs were created (IKE P2 was successful) but that was as far as I got.

It was a test to satisfy my curiosity.

Is CP to 3rd party route-based actually documented as being supported by CP?

Question for everyone tuned in here:

Are there many / any customers using route-based on CP VPN firewalls?

I suspect it is fairly rare but curious to know if it is in use?

Thanks,

Don

[PhoneBoy]

It should be supported with third parties, yes.

In fact, our Transit VPC solution in AWS uses Route-based VPNs: CloudGuard for AWS - Security Transit VPC Demonstration

[Kurt_Abela]

Is the tunnel up but no traffic passing or is the tunnel still down?

Try using 'Empty Group' as the Encryption domain for both Checkpoint Gateway and Interoperable device and select 'One VPN tunnel per Gateway Pair'

Donald Paterson‌ we use Route Based VPNs at many of our customers. We are also replacing many policy based VPNs with route based tunnels, even between Checkpoint and non-Checkpoint devices.

[Don_Paterson]

Thank for the info Kurt. 🙂

That's interesting to know. 

When you say policy based (maybe you're using other vendor terminology) do you mean domain-based?

Do you have it anywhere that it's official supported by TAC or R&D and therefore Check Point?

What's the main driver for doing that conversion? I guess dynamic routing or multicast streaming but...

Do you ever use VPN Directional rules with those deployments or stick with 'normal' rules (VPN domain objects)?

Thanks,

Don

[Kurt_Abela]

Hi,

Sorry for the delay

Policy based = domain based as some vendors use different terminology. It is actually supported by Checkpoint.

Main driver is dynamic routing but it is also to an extent easier to setup route based VPNs due to lack of encryption domains. Adding a new network to the VPN is simply adding a static route (or better using dynamic routing)

Since when using route based it is similar to creating a virtual link (VTI) between the gateways, we usually stick to 'normal' rules. Traffic is routed to other peer using static/dynamic routes and limited via normal access rules.

[Di_Junior]

Hi Kurt

I am struggling to setup a Route based VPN between Check Point and Cisco. Any special recommendatio you would give? It is my first time to configure Route based VPN.

[Martin_Raska]

Hi,

my question is, is there support to run both Domain based and Route based VPN on the same GW? With the empty encryption domain, I guess not. Thx

[Kurt_Abela]

If you need to run Domain and Route Based VPNs on the same Gateway you have to define encryption domain for that gateway. Just select the below option for the Route Based VPN.

[Don_Paterson]

But you should be specific about the peer domain I guess and expect that domain-based VPN encrypt (and decrypt) will take precedence over route-based.

The way I think about it is that the decision to encrypt based on domain (assuming no empty encryption domains exist) is based on the domain information and that happens on the ingres (in chain). 

If there is no domain match (SRC and DST) then it's left to the routing table to push the packets into the vti based on the next hop (being on the other side of the vti (on the VPN peer)). 

[Kurt_Abela]

Selecting 'one vpn tunnel per gateway pair' should send 0.0.0.0/0 as the encryption domain, thus traffic will not match to any encryption domain and will only be forwarded to VPN via the static/dynamic routes configured to use the VTI.

[Aidan_Luby]

I believe you should be able to do both based on a statement in SK113735 where it says: "In SmartDashboard, in the 'Gateway object Topology tab > In the VPN Domain section > Manually defined', select the empty group that you created in step 1. NOTE: If same Gateway is participating in Domain based VPN then the empty goup should be added within the VPN Encyption Domain Group defined."

So I take that to mean if you have a network group full of networks to be included in a domain-based VPN that the gateway is participating in and you also want a route-based VPN using that gateway you add the empty network object to the network group used for the VPN domain on that gateway.

Edit: I stand corrected, based on information from SK109340

"Domain Based VPN will take precedence over Route Based VPN for conducting the VPN traffic if the connection's source and destination are included in a Security Gateway's encryption domains, and if both Security Gateways are included in the same VPN community.

In this scenario, since there is a match for the connection's source and destination, even though Route Based VPN is configured for this connection's source and destination, the connection will be handled by Domain Based VPN (for routing decision, etc.)."

[Yonathan_Grunew]

If i understand correctly,  you might not have to stand corrected. 

According to the statement from SK109340, domain based VPN only takes precedence if both SGs are in the same VPN community. 

Let’s give an example:

(gw-a ——- {gw-b) ——- gw-c}

gw-a is in the same (community) as gw-b, a domain based vpn, with domains of 10.10.10.0/24 for a, and 10.20.20.0/24 plus an empty group for b. One tunnel per gw pair.

gw-b is in the same {community} as gw-c, a route based vpn, with domains of 0.0.0.0/0.0.0.0 for c, and 10.20.20.0 plus an empty group for b. One tunnel per gw pair.

Theoretically, is it possible to use domain based and route based on the same gateway, in order to achieve selective vpn routing - e.g host in 10.20.20.0 (behind gw-b) could use vpn to gw-a to get to 10.10.10.0 resources, while using vpn to gw-c as a universal tunnel to the internet, let’s say through a web security service, as mentioned In sk119034? 

[Bob_Zimmerman]

You don't need to add an empty group. The reason empty groups are used is you have to set the VPN domain to something.

Domain-based VPN logic grabs the traffic very early and flags it for encryption to a peer. Once that happens, the routing decision gets overridden, and all kinds of other stuff happens internally. To use a VTI, you need to avoid all of that.

The domain-based VPN matching logic asks two major questions we care about here. Is the destination is in a peer's encryption domain? Is the source in my encryption domain? If both of those are true, flag the packet for encryption to that peer. To disrupt this, you can either remove the destination from the peer's encryption domain, or you can remove the source from mine. The simplest way to do so is to use an empty group as the encryption domain for one or both gateways participating in the negotiation.

You can have a gateway participate in both domain-based and route-based VPNs. For route-based peers, set the peer's encryption domain to an empty group. The problems start if both gateways are managed by the same SmartCenter, you want them both to participate in domain-based VPNs with other gateways, but you want route-based VPN between them. I haven't tried this, but I believe you could get things working between them by setting the community between them to use gateway-to-gateway tunnels. Some traffic would match based on VPN domains, and any which didn't should be able to cross using the same negotiated keys and the VTI.

As an aside, this domain matching logic is also the cause of "Received cleartext packet within an encrypted connection" and "According to the policy, this packet should not have been decrypted". Those are the VPN equivalent of antispoofing.

If a packet is received (but not decrypted), the source is in a peer's encryption domain, and the destination is in my encryption domain, drop with the message "Received cleartext packet within an encrypted connection".

If a packet is decrypted, the source is not in the peer's encryption domain, or the destination is not in mine, drop with the message "According to the policy, this packet should not have been decrypted".