VPN routing between two domains based communities

[HighTech]

Hello Community,

I wonder if kindly someone can help me understand and configure VPN routing between two different domain based communities, the topology is as follow (using One Checkpoint security gateway 1400 appliance running r80.20 and two Cisco ASA's):

ED (A) Cisco ASA A>>>>Checkpoint ED (B) VPN community-1

Checkpoint ED (B) >>>  Cisco ASA C ED (C) VPN community-2

We would like to have users in site A reach users in site C only . (From C to A is not needed)

How can I accomplish this ?

[Vladimir]

If I understand the question correctly, you are trying to use Check Point 1400 appliance to filter the traffic between two EDs behind Cisco ASAs. The problem with this approach is that in order for each ED behind Cisco to forward encrypted traffic through Check Point, the other Cisco ED must belong to Check Point community. Unless you NAT both Cisco EDs to phantom IP ranges and include those in Check Point ED, the traffic will be decrypted on Check Point and not forwarded.

You should be able to do that at a cost of some headache if your 1400 is managed by SMS. If it is locally managed though, I'd defer to better minds than mine to suggest how this could be accomplished.

[HighTech]

Does VPN routing between communities apply only to Checkpoint security gateways ? or third party gateways are also supported for this feature ?

[Bob_Zimmerman]

VPN routing works with non-Check-Point VPN endpoints, but they need to be within the same VPN community.

You might be able to use per-community VPN domains to tell the community with ASA 1 that your Check Point box's encryption domain includes ASA 2's domain, and the community with ASA 2 that your Check Point box's encryption domain includes ASA 1's domain. I haven't personally tried this before, and I can think of a few reasons it might not work. If you can't put both ASAs into the same VPN community, that's your best bet.

You could also move away from domain-based VPNs entirely and use route-based. That lets you set up a tunnel interface on the firewall to each peer. Then routing works just like it does with any other interface.

[Marcel_Gramalla]

You are correct about that the ASAs have to know about the other subnets of course so they build the tunnels to the Check Point accordingly but they don't have to be in the same community. You just have to choose the second option under "VPN routing" in the communites. The Check Point gateway don't have to include all subnets in their own encryption domain. They will accept the tunnels once they know they belong to a different community.

We use this quite a lot because we have many smaller partners that we bundle on our side and do VPN routing to other partners. 

[HighTech]

Thank you Marcel for your prompt reply. 

How about the security rules that I should implement for that to work ? (Knowing that I already have 2 existing rules for each community traffic to and from checkpoint).

[Marcel_Gramalla]

You can either use the directional VPN match so the rule could look like this: Src: ASA-netA dst: ASA-netC VPN: ASA-comA -> ASA-comC

Or just enter both communities in the VPN column without any direction. (Directional match has to be enabled in the global properties if you want to use that).

[HighTech]

Got it thanks. 

There is no need to edit this file $FWDIR/conf/vpn_route.conf ? Choosing the second option in VPN routing section on each community is sufficient for that to work ?

[Marcel_Gramalla]

No, no need to edit any file.

[HighTech]

Did you verify this setup ? did it work ? I am quite confused referring to what is stated in this SK: supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk164417

Could you please explain the difference if any ?

[Marcel_Gramalla]

We have many VPN that work this way. The sk is a bit confusing in my opinion but look at the sk that is mentioned in step 1: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

It seems this sk is only valid for Smart LSM and not for a regular setup. I assume you don't use Smart LSM.