Create a Post
Roh_oh
Explorer

VPN tunnel between checkpoints

Jump to solution

Hi, guys nice to be part of this community.

This is my first time with checkpoint and I'm facing bizarre behavior.

We have a Check Point Gaia R81.10 cloud version running on AWS; on the other hand, a Cluster XL 81.10.

Both of them have multiple (at least 5) IPsec VPN tunnels to different non-checkpoint gateways that are working without any problem. We use those tunnels to share BGP routes between the gw and CP-FWs

The issue starts when we try to create a VPN tunnel with the CP on AWS and the Cluster using the next config.

VPN COMMUNITY: TEST 

Star Community 

center: CP-AWS  Satellite: CP-CLUSTER XL

VPN domain route-based,

allow traffic,

any encryption,

tunnel management per gateway no permanent

and then everything by default 

As soon as we create the tunnel we saw in the Checkpoint smartview Monitor that the tunnel was created with the incorrect members.

Like: on TEST community CP-CLUSTER XL to NONCPGW(an interoperable device)

They are not (CP-AWS and the NONCPGW) in the same subnet or something similar, the only thing that they share is that both of the CP-FW have a tunnel and a session BGP to this NONCPGW.

Did you face this behavior before? maybe an SK related? 

Thank you

 

 

 

0 Kudos
2 Solutions

Accepted Solutions
Duane_Toler
Advisor

You definitely want to consider calling TAC to verify your configuration.  At first glance, this looks like you are running into the known collision between route-based VPN and domain-based VPN (VPN encryption domain groups).  To work around this, you can define VPN domains-per-community for each gateway.  Be sure you have an empty object group (yep, a group with zero objects in it).  Edit the community, select the center and start gateways, then edit the VPN domain on each gateway to use the empty group object.

I'd also suggest unchecking "allow all encrypted traffic" in the community.  This could lead to these sorts of unintended consequences, but you can try with/without it.

 

Typically, for route-based VPNs, you need to use VPN Directional match in the rules.  You first need to enable directional match in Global Properties - VPN - Advanced.  In a given VPN rule for those gateways, edit the VPN column, and choose "Directional match" option, and create three separate entries:

internal_clear -> <community name>

<community name> -> internal_clear

<community name> -> <community name>

You said you have BGP between VPN peers, so I presume you have VTIs configured and operational.  You will want to review your route-maps to make sure you are dong AS PATH filtering, possibly pre-pending, to make sure you don't have one gateway end up being an inadvertent hub (unless you want that; but then you have to edit your VPN directional match rules to allow traffic to flow correctly).

 

Good luck!

View solution in original post

the_rock
Champion
Champion

I agree with @Duane_Toler , he brought up very good points. You also need to consider the following things...

-empty enc domain for the 3rd party

-VTI (virtual tunnel interface) config

-vpn config file from AWS side

Check out below post where I provided some info, hope it helps. If you need clarification, happy to help you. I get its CP to CP, but since AWS platform is involved, it may have to route based.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-failover-issue/m-p/155553#M265...

View solution in original post

5 Replies
PhoneBoy
Admin
Admin

Not sure how the gateway would handle getting the same set of routes from multiple gateways with Route-Based VPN.
The only thing I can suggest outside of a TAC case is to filter the relevant routes from the other peer.

Duane_Toler
Advisor

You definitely want to consider calling TAC to verify your configuration.  At first glance, this looks like you are running into the known collision between route-based VPN and domain-based VPN (VPN encryption domain groups).  To work around this, you can define VPN domains-per-community for each gateway.  Be sure you have an empty object group (yep, a group with zero objects in it).  Edit the community, select the center and start gateways, then edit the VPN domain on each gateway to use the empty group object.

I'd also suggest unchecking "allow all encrypted traffic" in the community.  This could lead to these sorts of unintended consequences, but you can try with/without it.

 

Typically, for route-based VPNs, you need to use VPN Directional match in the rules.  You first need to enable directional match in Global Properties - VPN - Advanced.  In a given VPN rule for those gateways, edit the VPN column, and choose "Directional match" option, and create three separate entries:

internal_clear -> <community name>

<community name> -> internal_clear

<community name> -> <community name>

You said you have BGP between VPN peers, so I presume you have VTIs configured and operational.  You will want to review your route-maps to make sure you are dong AS PATH filtering, possibly pre-pending, to make sure you don't have one gateway end up being an inadvertent hub (unless you want that; but then you have to edit your VPN directional match rules to allow traffic to flow correctly).

 

Good luck!

the_rock
Champion
Champion

I agree with @Duane_Toler , he brought up very good points. You also need to consider the following things...

-empty enc domain for the 3rd party

-VTI (virtual tunnel interface) config

-vpn config file from AWS side

Check out below post where I provided some info, hope it helps. If you need clarification, happy to help you. I get its CP to CP, but since AWS platform is involved, it may have to route based.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-failover-issue/m-p/155553#M265...

Roh_oh
Explorer

Thank you guys, your clarifications are very useful!

Agreed with all your comments I will follow this with the TAC. I find a workaround, using ike2 only but is not a solution for me. 

Thanks again

0 Kudos
the_rock
Champion
Champion

Glad the post helped you. As I said, if you need more clarification, let me know!

0 Kudos