AWS deployment with VSX on-prem gateway

[Ole_Jakobsen]

Hi,

I'm trying to do a deployment of CG in a AWS Transi VPC.

I have read the guides Transit VPC for AWS R80.10 Deployment Guide and CloudGuard for AWS - Transit VPC Architecture, I have watched the video Step by Step deployment of automated, multi hub Transit VPC.

One thing that is described in every guide is to make a VTI between the on-prem gateway via the Direct Connect (DC) to the gateways in the Transit VPC.

My challange is that the on-prem gateway that is used to connect to the DC is a VS on VSX where VTI is not supported. (See: VSX supported features on R75.40VS and above)

As I understand the VTI is primarily used with the BGP peering so the peers is directly connected.

Then my solution to the unsupported VTI on VSX is to use BGP multihop os I don't need the VTI.

Can any of you see any issues with this solution?

I'm looking forward to any reply to this question 

Cheers

Ole J

[Yonatan_Philip]

Hi Ole,

If you are not using the VTI does this mean you plan to send traffic between your on-prem and the TransitVPC gateways in the clear over the internet or were you planning to use domain-based VPN instead?

[Ole_Jakobsen]

Hi Yoayan,

Thanks for your reply.

I have a Direct Connect line, which is a closed circuit from on-prem directly to a AWS region Data center. Therefore, no traffic from on-prem to AWS will transmitted over the internet.

The guides say that either way, Direct Connect or internet, you have to use VTI to connect your on-prem gateway to the gateways int the AWS Transit VPC, because of the BGP peering.

As I run VSX on my on-prem gateway that terminates the Direct Connection, I can't use VTI because it is not supported on VSX.

Therefore, I was think that I could skip the VTI interfaces and use BGP multihop for the peering between my on-prem gw and the Transsit gw.

My only concern is, will it work with BGP multihop?

Cheers

Ole

[Yonatan_Philip]

Hi Ole,

Can you point me to the exact place where it says you need VTI when using Direct Connect? 

I think it might be a mistake (I could be wrong, but that doesn't sound right...).

I haven't had much experience with Direct Connect (or with VSX for that matter) but as far as I know, it supports BGP so I suspect it will just work.

This can be easily tested - create a CP GW on a VPC and just test BGP and connectivity between your VSX and a single CP gateway.

The VTI is mainly used for the VPN tunnel. It's true that the BGP has a single hop, but since Direct Connect should support BGP I assume it's propagated along the route - again should be easily verified.

HTH

 Yonatan 

[Ole_Jakobsen]

Hi Yonatan

This diagram is from sk120534 and uses a Direct Connect.

The SK uses VTI. It is also mentioned in the articles and guides I listed above. In the articles similary pictures is used both DC and VPN over internet is showed as exsamples for the same VTI configuration.

I hope that clarifies it.

I'll try to set up a test with BGP multihop.

BGP is supported in a VS on VSX.

Cheers

Ole

[Arnfinn_Strand]

Hi,

This diagram is the typical way to do it.

The VTI's are between the CloudGuard gateways and the AWS VGW which is unattached and connected to DirectConnect.

So no need for VTI's in On-prem gateway.

Arnfinn

[Ole_Jakobsen]

Hi Arnfinn,

Thanks for your reply.

If I understand you correct, BGP multihop is the way to go if I use Direct Connect?

Cheers

Ole

[Arnfinn_Strand]

Well, if you create Route-Based VPN's between the CloudGuard gateways and the AWS VGW, you don't need BGP Multi-hop. BGP will run over the VPN between CloudGuard gateways and the AWS VGW. This is single hop.

Arnfinn

[Ole_Jakobsen]

As I understand Route-Based VPN it is based on VTI interfaces. VTI is not supported on VSX.

Ole

[Arnfinn_Strand]

VTI is currently not supported on VSX.

As I understand you don't need encryption for the traffic over the DirectConnect, so there is no need to have VTI support on the On-prem gateway.

There are Route-Based VPN's (uisng VTI's) between the CloudGuard gateways and the AWS VGW. Between the AWS VGW and On-prem there is the DirectConnect without VPN.

Arnfinn

[Ole_Jakobsen]

So with no direct link (eg VTI) between on-prem gw and CG gw BGP multihop is needed for the peering to work. Right?

/O

[Arnfinn_Strand]

Hi,

I don't see why. There will be an other BGP peering between the AWS VGW and On-prem (or Service Providers BGP router).

Arnfinn

[Ole_Jakobsen]

Ok. I was just so hung up on the fact that I thought the Check Point gateways had to peer because that was how its described in the docs. Or at least that was how I read it.

So in short:

On-prem gw BGP peer to Service provider of Direct Connect router

GC gw BGP peer with VGW in Transit VPC

Ole

[Arnfinn_Strand]

The VGW is not "in" the Transit VPC or any other VPC, it is unattached.

In short:

On-prem gateway BGP peer to Service provider BGP router of DirectConnect (optional)

Service provider BGP router of DirectConnect BGP peer to unattached AWS VGW.

unattached AWS VGW BGP peer to both CloudGuard gateways

Arnfinn

[Mauricio_Hurtad]

Hi 

I already attempted this configuration trying BGP multi-hop.  It didn't work. The VPN tunnel came up because it was set to create a tunnel per gateway under tunnel management.  I our logs we observed that AWS was always attempting to do BGP peering with the VTIs we were supposed to be configured.  This is bad because the only way we were able to connect to AWS was using static routing VPN without possibility of using ECMP, and high availability across availability zones.

[Yonatan_Philip · Accepted solution]

I was really hoping you weren't going to use that diagram

I am 100% to blame for that.

I created this diagram. This was originally two diagrams - one with Direct Connect and one with VPN.

Since they were basically the same with such a minor difference between them we decided to combine them into one diagram to improve the readability of the SK and explain in the text that you can use either one.

The connection is established via a secured VPN connection between your Check Point Security Appliance and a CloudGuard Gateway for AWS. You can also implement a secure connection with AWS Direct Connect tunnels.

At the time we spoke with a few customers and they said it was clear, but it was a very small sample size and there was always the worry that this will be misconstrued to mean you need both a VPN on top of the DC.

So just to put this to bed - you can use either a VPN connection or a Direct Connect connection - no need for both.

HTH 

 Yonatan 

[Ole_Jakobsen]

Then that settles it

Thank you for your help and I'm sorry that I didn't understand the documentation first time I read it

/O

[Mauricio_Hurtad]

I went through the whole comments.  Thank you for sharing.  I have a similar issue.  We are implementing Direct connect, but for now we have a VPN using a VSX virtual system to connect to a VGW.  We want to migrate that VPN connection to an actual pair of Cloud Guard Transit gateways.  When we do that VPN is established, but the request flows between a transit Cloud Guard FW in AZ1, which is routed through transit VPC, to its corresponding EC2 instance in a different VPC, in a a specific AZ.  The reply from that EC2 instance is routed through a transit Cloud Guard FW in AZ2 (Which is blocked because it is asymetric,  this CGFW didn't see the SYN coming). 

I got two different suggestions:

1. Checkpoint support mentioned that to fix this I was supposed to configure BGP between CG transit FW, and on-prem (VSX that doesn't support VTIs).  My question is:  is possible to setup BGP over two different VPNs using public IPs and private ASN between two CG transit FWs, and on-prem VSX?.  Will this fix my issues regarding asymmetric routing?

2.  Somebody else was mentioning to configure MEP on actual CG transit FWs to select an active, and a standby CG FW.  At the same time configure BGP routemaps with different priorities to make always a CG FW Active, and other one Standby.

Another question I have is:  Will this BGP implementation on my actual VS VPN firewall cause any potential impact on my other actual VPNs with third parties?.

Thanks for all suggestions I can get from you.