VPN routing between 3rd party A VTI VPN --> CP --> 3rd Party Domain based VPN

[Darren_Fine]

Hi there,

I have a client who has 2 vpns between 3rd parties like so :

1) VTI route based VPN between 3rd party (SiteA) and (HUB CP Gateway) (own star vpn community)

(SiteA- 10.0.0.0/13) ----routed VTI-------- (HubCPgateway - 172.16.9.0/24)

2) Domain based VPN between 3rd party (SiteC)and (HUB CP Gateway) (own star vpn community) (using one tunnel per Gateway setting) 

(HubCPgateway - 172.16.9.0/24) ----Domain Based VPN---(SiteC- 10.200.0.0/19)

Now for whatever reason the client wants to route traffic between the two third party sides (they own the equipment at the 3rd party sites and need to replicate).

So wants Site A and SiteC to talk via HubCPGateway like so :

(SiteA- 10.0.0.0/13)-------routed--VTI------(HubCPgateway- 172.16.9.0/24)-------Domain Based VPN------(SiteC- 10.200.0.0/19)

I tried to ADD the networks in SiteC into HUB CPGateways encryption domain and just route the traffic from SITEA via the routed VTI . The traffic does come down the vpn but then gives the traffic gives the error "according to policy packet should not have been decrypted " .

I also tried to ADD networks in SiteC and SiteA into HUB CPGateways encryption domain this made no difference. I was thinking that R80.40 which allows for different encryption domains per vpn community may assist me with this.

(or do I need to change a user.def file ? )

I did see a whole section in the manual where they use the vpn_route.conf file to route traffic between vpns but in that scenario all the gateways were CP gateways and managed by the same Management station.

Is it possible to do it with R80.30 ? If yes how ?

If not do you think it will be possible with R80.40 ?

Thanks in advance.

[PhoneBoy]

You're talking about route-based VPN and Encryption Domains.
The encryption domain for a route-based VPN is 0.0.0.0/0.
Routing to the VTI interfaces determine what is encrypted.
This isn't any different in R80.40

[Darren_Fine]

Hi Phoneboy, 

Only one of the vpns is a VTI. 

The other VPN is a normal domain based VPN. 

As mentioned customer wants to route via the check point "hub" from the one to the other. 

(obviously there are additional vpns that I don't want to break in the process) 

Thanks

[PhoneBoy]

Ok, that kind of makes sense.
Note that when you mix route-based VPNs and domain-based VPNs on the same gateway, the configuration for domain-based VPNs applies first.
Which means: your domain-based VPN configuration should not include anything covered by the route-based VPN configuration.
You might need to use IP Pool NAT here to ensure traffic is routed back and forth correctly in this instance.

[Darren_Fine · Accepted solution]

Hi ,

This did work with the help of the R80.40 different Encryption domains for each community. (could not do it without this)

Also used the vpn_route.conf to allow the inter vpn routing on the Check Point Hub Gateway. (only for traffic to go into the Domain based VPN - the VTI just worked with routing.)

No nat necessary but obviously the correct routing was required on both the 3rd party VTI VPN side and the 3rd party Domain based side.

Very impressed this worked:-) Love R80.40 now!!!

First time I have ever seen the VPN routing Icon --great stuff!!

[Ara_Zohrabian]

Hi, i have the same issue with vpn_route.conf. How do you put Interoperable Device in your vpn_route.conf ?

Thanks

[Darren_Fine]

Hi Ara_Zohrabian,

The format I used was

<Remote_Encryption_Domain_subnet> <Remote_vpn_peer> <Local-Gateway>

All the names are as per the objects names in the policy.

Hope that helps.

Regards

[Ara_Zohrabian]

Hi, to be able to reach 10.200.0.0/19 (SiteC) from 10.0.0.0/13 (SiteA), you must add 10.0.0.0/13 in the HubCPgateway encryption domain to SiteC. But i am always receiving the error "according to policy packet should not have been decrypted" because 10.0.0.0/13  cannot be in both VPN (route base VPN and the domain base VPN). Do you have an idea?

Thanks

[PhoneBoy]

You can't have overlapping encryption domains regardless of whether it's domain or route-based VPNs.
That can only be resolved by renumbering or NAT.