VPN Routing between Domain Based and Route Based VPN

[HighTech]

Hi Experts,

I have a scenario that I need your help on!

I have a customer who has the following setup: (2 separate VPN communities ) 

Cisco ASA --->Domain Based VPN--->Checkpoint--->Route based VPN----> Third party firewall

Users behind ASA need to talk to users behind third party firewall. 

1) Can routing between the two vpn communities happen ? if yes, what needs to be done at a high level ?

2) if the routing between vpns is happening correctly, I have a network behind 3rd party firewall that is reachable through a static route from checkpoint through an MPLS network. The desired behaviour is to use the static route through MPLS as a primary route and the routing through the route based VPN as a backup route. Can this be accomplished by assigning a lower metric to the static route that leads to MPLS and configure path monitoring to disable it if the destination network is not reachable ?

Thanks in advance.

[the_rock]

There is an option for routing inside vpm community object, sounds like thats what you need.

Best,

Andy

[HighTech]

Will this work even I have two different vpn communities ? I only need to enable the vpn routing on each community ? What option to choose then ? To Center only? And what about the security rule ?

any insight regarding question 2 ?

Thank you!

[the_rock]

I would say center only. As far as the rule, make sure its allowed based on the traffic flow. You may need 1 rule per each community.

Andy

[HighTech]

Thanks for your reply. Could you please elaborate in more details on this ? How should the security rule(s) look like ? Is there any directional match involved ? Also, should the 3rd party gateway set the subnets behind the ASA as the encryption domain for Checkpoint ?

[the_rock]

For route based VPN, you need to enable vpn directional match setting in global properties, I think its under vpn and then advanced (at the bottom), then in thr ule vpm culumn, you need 3 "entries", internal to vpn comm, vpn comm - vpn comm and then vpn comm to internal

As far as enc domain, think of it this way...regardless if we are talking about CP, PAN, Fortinet, Cisco, Sonic Wall, makes no difference...vpn domain will ALWAYS be whatever is local behind that fw, so for 3rd party, end domain is subnet thats behind that fw, unless if its route based, then most likely empty group

route based vpn -> vpn domain = empty group

domain based vpn -> vpn domain = local subnet

HTH

Andy

[HighTech]

Thanks for your reply! but I think I misscomunicate this.

My actual need is to make routing between a domain based VPN and route based VPN through checkpoint.

Site A Cisco ASA --->Domain Based VPN--->Site B Checkpoint--->Route based VPN----> Site C Third party firewall

The configuration you specified is only for the route based VPN setup to make the tunnel work between SiteB and SiteC.

I need users in Site A communicate with networks behind Site C through Checkpoint. 

Thanks!

[the_rock]

Sounds like you need to enable vpn routing on domain based community.

Andy

[HighTech]

I have on last question sir. I am confused about what option to choose in vpn routing:

option 2 says: To center and to other satellites through center. Use VPN routing for connection between satellites. Every packet passing from a satellite gateway to another satellite gateway is routed through the central gateway. Connection between satellite gateways and gateways that do not belong to the community are routed in the normal way.

option 3 says: To center, or through the center to other satellites, to internet and other VPN targets. Use VPN routing for every connection a satellite gateway handles. Packets sent by a satellite gateway pass through the VPN tunnel to the central gateway before being routed to the destination address.

So I think that option 3 is more suitable. What do you think ? and also to confirm this setting is needed on the domain based community only since we have traffic in one direction only (from A to C through B). I am I right ?

Thank you

[the_rock]

1) You can call me Andy, Im not that old...well, 44 🙂

2) You did not bother me via email, its a free country, I can easily choose to ignore or delete your emails 🙂

and 

3) Yes, I would agree option you mentioned is best suitable.

Best,

Andy

[HighTech]

Thanks Andy! appreciate it!

and also to confirm this setting is needed on the domain based community only since we have traffic in one direction only (from A to C through B). I am I right ?

[the_rock]

Correct. As @emmap had indicated, think of it this way...route based VPN tunnels utilize routing via VTI, so say for example if you have unnumbered VTI of your external interface, that would send the traffic using that interface for the tunnel. Most vendors are now abandoning domain based vpn tunnels. I believe PAN does not even let you create them any longer, Fortinet does, but literally everyone uses route based ones. 

Best,

Andy

[emmap]

For question 2, route based VPNs do routing same as if it were just an interface, so something like that ought to work if the monitoring is good. You might need to play with that and test it a few times to make sure it's reliable in all failure scenarios.

[starmen2000]

One additional question about this topic. If there is a static route to different next hop and also for this subnet if there is a domain based route exists, how does it work Routing? Which one has more priority?

[the_rock]

I believe only PBR routes would take precedence over static route itself.

Best,

Andy

[starmen2000]

For example there is one subject 10.16.0.0/16 internally routed to another internal router and you are using 10.16.10.0/24 subset as encryption domain for site to site domain based VPN for 3.partner. In this case would firewall domain based vpn routing work or because of static route would it not work?

[the_rock]

Technically, for vpn tunnel itself, you dont need to add routes manually, Now, if /16 is already there, that included range 10.16.0.1-10.16.255.254, so it should work.

Andy

[emmap]

Domain based VPN takes priority over route based.