Managing r80.10 AWS vSEC from On-Prem SMS via existing VPN

[Vladimir]

Experts,

Please chime-in: I have a pre-existing VPC on AWS with On-Prem CheckPoint to VPG dual-tunnel VPN in place.

Now the client wants to expand his security in VPC by introducing Check Point R80.10 vSEC gateway for both: outbound and inbound connections to and from Internet.

I have no problem deploying vSEC with two NICs, ammending the routing tables and security groups as well as establishing SIC.

First policy push, no changes to the policy, just vSEC object present, brakes it all.

Additionally, the on-prem SMS to AWS Data Center connection (using Access Key ID and Secret Access Key), does not work via pre-established VPN. It requires SMS to access this data from the Internet only.

I cannot be the only one in this situation, it seems pretty common topology to be unique.

Any suggestions?

[PhoneBoy]

Management traffic is excluded from VPN generally speaking.

The logic for this is simple: if the VPN breaks, so does your ability to manage the Security Gateway.

Likewise, the vSEC Controller would cease to receive updates if your VPN went down.

While there is probably a way to force this traffic through the VPN--will move this into the https://community.checkpoint.com/community/cloud-vsec?sr=search&searchId=3985f9e8-170f-40c1-bdb9-bd3...‌ space so the correct R&D can comment--I don't recommend it.

[Vladimir]

Can you elaborate on how the routing decision is being made by the Management Server as well as an On-Prem gateway  and the vSEC, in this case?

If the vSEC is known to the Management Server only by its Internal IP, (and topology, once it is extracted), and its subnet is included in the On-Prem Gateway's routing table, how would the:

1. Management Server become aware of the vSEC's Elastic IP address?

2. vSEC will be able to determine where to send the logs, (especially, if the Management Server object does not have the Static NAT configured)?

Just to remind you, the pre-existing VPN is between the On-Prem Gateway and the AWS VPG.

Thank you,

Vladimir

[PhoneBoy]

The management server just follows it's normal IP routing table.

The on-premise VPN gateway, assuming it receives the traffic, would determine whether or not to encrypt the traffic depending on the source/destination of the packet.

Some traffic (namely management traffic) is actively excluded, even if the source/destination are in the encryption domains.

In this case you either need to:

• Configure a static NAT for the manager for the vSEC gateways (see Troubleshooting "SmartCenter behind NAT" issues)
• Configure SIC to operate over VPN (not recommended, see Firewall Control Connections in VPN Communities in the R80.10 Site-to-Site VPN Guide)

The vSEC Controller has to talk to the AWS APIs directly to get information about EC2 instances as they come up.

This traffic should not go through the VPN at all.

Once you resolve this, the gateways should be able to communicate with the vSEC Controller over either private IP addresses, or public IP addresses.

Communication over private IP addresses is possible in any one of the following cases:

• The management is in the same VPC as the vSEC Security Gateways.
• The management is in another VPC that is peered with the VPC, in which the vSEC Security Gateways are deployed.
• The management is in an on-premises network that has connectivity to the VPC over Direct Connect.
• The management is in an on-premises network that has connectivity to the VPC over a VPN connection.

[Vladimir]

Dameon,

According to the docs:

Allowing Firewall Control Connections Inside a VPN

"If you turn off implied rules, you must make sure that control connections are not changed by the Security Gateways. To do this, add the services that are used for control connections to the Excluded Services page of the Community object. See sk42815 for details."

So, for the 

• The management is in an on-premises network that has connectivity to the VPC over a VPN connection,

as no Implied Rules were disabled, I would've expected the SIC encrypted traffic to traverse the VPN, be decrypted on the other end and continue to function, (via SIC encapsulated connection), but that was not the case.

[PhoneBoy · Accepted solution]

SIC does not go through the VPN by default precisely because of the Implied Rules.

If you disable the implied rules, SIC traffic will go in the clear unless you exclude them.

As noted, this is not recommended as if there are any issues with the VPN, you may lose the ability to manage the gateway entirely.

[Vladimir]

Thank you. I ended-up NATtting the SMS, as you have suggested.

Can you explain the function of the 127.0.0.1 host in the context of the Identity Awareness for AWS , which gateways it should be assigned to and how / where the secret associated with it is being used?

[PhoneBoy]

The mechanism that vSEC Controller uses to update the gateways on the addition or removal of AWS objects is the Identity Awareness API.

For this to work, updates via the API must be permitted from 127.0.0.1 (localhost) on all your AWS gateways.

While the IDA API does require credentials in general, and are configured in the gateway object in SmartConsole, they are not required for localhost.

[Vladimir]

So this property should only be enabled, and the localhost object added on

vSECs only, or on all the gateways, including physical and virtual that may

have rules defined that contain the cloud-based (datacenter) objects?

[PhoneBoy]

Only on the vSEC gateways.

The other (physical, on-premise) gateways should receive the same information through Identity Sharing.

Configure the following in each Check Point gateway object:

[Vladimir]

Hmm. no dice... When configuring an On-Prem Gateway with suggested above settings, am seeing:

[PhoneBoy]

Is this on your vSEC gateway?

Identity Web API does not need to be enabled on your non-vSEC gateways (unless you need it for another reason).

What's shown in the Settings (button next to Identity Web API)?

[Vladimir]

I have removed the IW API from the GW8010 (On-Prem GW), and the Identity Sharing from vSEC, This cleared-up the alert. I guess my confusion stems from misunderstanding of when it is necessary to share the identities:

I thought, that if you want to use the Datacenter objects in the rules applied to the On-Prem GW, you have to have IDA integrated across all the Gateways, vSECs and physical alike.

[PhoneBoy]

You have it right.

If you're not using the AWS objects in your on-premise gateway policies, it's not strictly required to share the identities.

[Vladimir]

Dameon, than you for your help today: it really nice to get some concise information.

If I can trouble you for one more issue:

I am placing a number of Web Servers behind Logical Server object for the load balancing purposes. The Elastic IP 2 in the diagram is assigned to the Logical Server object.

When NAT Hide on the Net-10.255.255.192/26 is disabled, servers are reachable.

However, one additional pre-requisite is to have the same servers accessing Internet repositories via vSEC.

I am experiencing a minor mental stupor trying to solve this issue: Enabling Hide Nat on the 10.255.255.192/26 allows outbound access but, unsurprisingly, breaks the inbound. 

What is the best way for having and eating the cake in this situation?

[PhoneBoy]

FYI, for proper autoscaling support, refer to the reference architecture here: Auto Scaling in Amazon Web Services (AWS) 

In the demo environment built as part of Leveraging the R80.10 API to Automate and Streamline Security Operations‌, a separate vSEC gateway was built for protecting outbound traffic from the gateways used for protecting inbound traffic.

The reference architecture speaks of using the existing vSEC gateways in proxy mode for outbound (not routed/NAT).

I'm guessing the problem you are running into is why the above alternative approaches are used instead.

[Vladimir]

Ouch... Well, I guess I should be happy with "It isn't just me":)

Thank you fr the references to the auto scaling, I will certainly read through those. I have to pretty much build multiple scenarios for the demo lab for my clients and am starting with the easiest one.

Regarding Proxy Mode: I've been told that it is rather inefficient method of handling traffic in Check Point environment and that the Path-Through (with SSL decrypt and inspection) is far superior. Do you happen to know if it still holds true in R80.XX?

The Separate Gateway for outbound traffic sounds like a correct solution, (speaking from AWS perspective), but is also exceptionally hard to push on clients.

Thank you again and have an excellent evening.

[PhoneBoy]

I'm not sure proxy support is necessarily better in R80.10.

The autoscaling config is pretty easy to build from the provided CloudFormation templates as well as in the demo scripts in https://community.checkpoint.com/message/7699-leveraging-the-r8010-api-to-automate-and-streamline-se...‌.

Perhaps that can be the basis for some of the demos you're building for clients

[Vladimir]

Perhaps. On the subject of proxies, the transparent mode on the same gateway does not work, which I can attribute to the general treatment of HTTP traffic, regardless where it has originated.

I am thinking about the possibility of adding one more interface, choosing a non-transparent proxy and configuring it to listen on that newly created interface.

Next step is assigning the IP of that interface as a proxy to AWS AMIs, probably via bootstrap.

Does this sound right, or is the transparent proxy on the only internal interface should've worked?

[PhoneBoy]

I think explicit proxy is the only way to do it in this case.