How to setup a basic AWS vSEC with a VPN back to Home office?

[Sal_Bonaccorso]

We have been having major difficulties setting up the most basic configuration for our office.  We have spoken to 5 Checkpoint engineers over 3 weeks and still have not been able to get the firewall online.

Here is the layout and the request:

We have a central office that we VPN from to the AWS Checkpoint Vsec device.  We have 1 server in AWS in our VPC.  

We are trying to have all traffic coming into the VPC from our office go through the firewall and any traffic leaving the VPC go through the firewall as well. 

The issue we have is a routing issue.  We seem to not be able to get both the server and the Firewall to talk back to our central office.  We can see the firewall, and push policies, but cannot see the server behind it. In order for the Vsec device to get to the internet, there has to be a static route of 0.0.0.0/0 to inetgateway in your VPC, and then we place our internal subnets pointing to the interface on the Vsec device.

The traffic will go to the firewall, but never come back to the office. No pings, nothing.  Like a black hole.  All the rules are wide open.

I don't understand how the most simple AWS VPC deployment has brought a Vsec to its knees and no one can figure this out... 

[Jonathan_Lebowi]

Sal, on the routing table attached to the subnet of the internal server, the default route has to point to the internal interface (eth1) of the vSEC gateway, and not to the internet gateway.

For the subnet of eth0 of the vSEC gateway, the attached routing table should point to the the internet gateway.

See the attached drawing.

[Sal_Bonaccorso]

We have our built just like this except for the subnets are different.

Now... The VPN Connection goes directly to the Checkpoint from our corporate office and we are NOT wanting to route our corporate traffic through this firewall to go to the internet.  Consider this like a small branch office.

From our corporate office, the VPN tunnel IKE/IPsec are both up and green. Here are the facts:

1) We can reach the external (eth0) IP of the firewall.

2) We cannot reach the server on the internal subnet

3) The server on the internal subnet cannot communicate with anything, and we do not see any logs on the firewall, even though the default route table in the VPC says to use the internal (eth1) card of the Firewall for that subnet)

4) We have configured each side of the VPN connection to include the subnets of each locations so they are aware of how to route.

5) WE have configured a NAT rule on the firewall similar to Dameon suggested.  

6) Our routing table on the Firewall only has one entry and it is the default pointing to the .1 address of the subnet of the external eth0 interface.

What else could be missing?

[Jonathan_Lebowi]

The most likely misconfiguration and the first thing I'd do is check, from the aws console, on the ENI of eth1, that source/ dest checks are disabled on that ENI. (I'd do the same for the eni of eth0, but there it's unlikely that that check is enabled to begin with).

Next make sure in smartconsole-> gw properties->vpn->link selection, that the gateway is set to be behind NAT with the right ip address, ie, the EIP associated with the address of eth0.

Both these things are covered in the AWS getting started guide that i believe that Damian provided a link to above

Sent securely from my Android

[Sal_Bonaccorso]

1) Yep, we actually used the CloudFormation Template to build the machine, so it did all this for us.

2) Yes, both are set to the EIP assigned to eth0 on the device.

  

Like I said..4 engineers can't figure this out, but I feel like ti's something so small that is missing.  We have read the guides, we have tried building one from scratch and ones using the Cloud Formation templates, we have tried building 77.30 and 88.10 versions.. still it wont let things talk to each other.

Please help...

[Jonathan_Lebowi]

Next step would be to verify that no security group in aws is dropping the traffic. I suggest you open a ticket with support if you haven't already. We've done hundreds of these vpn connections....

Sent securely from my Android

[Sal_Bonaccorso]

Inbound and Outbound completely open.  Including Network ACLs.

I may have not been clear earlier... those 4 engineers... are Checkpoint Support Engineers.... hence why I am reaching out to anyone on this planet at this point.

[PhoneBoy]

Have you done a tcpdump on the relevant interface on the vSEC instance to verify traffic is even reaching the instance?

That should at least give us a clue where to go next.

[Sal_Bonaccorso]

Yes.  And it's not.

[PhoneBoy]

Which interface are we talking about?

If it's the Internet-facing instance, that should be receiving IPsec traffic, assuming the VPN is set up correctly.

If you're not receiving any IPsec traffic, that points to either:

• A misconfiguration on the remote end--please refer to the Getting Started Guide linked above.
• A security group (each instance/interface is associated with one) or network ACL that is blocking the communication.
• The Elastic IP may not be configured on the correct interface.
• Something upstream is blocking the IPsec traffic (not necessarily in AWS).

If you're receiving IPsec traffic and the gateway is not transmitting IPsec traffic, that points to a routing issue.

• The vSEC instance needs to have a default route configured (should be a x.y.z.1 address assigned by AWS on initial configuration).
• If you're using other subnets in your VPC and are using more than one interface, you will need to have a route for those other subnets through your other interface (also likely a .1 interface).

If you're talking about the interface between your vSEC instance and your server instance, then it's either a routing misconfiguration (on the instances or in AWS), an issue with security groups, or an issue with network ACLs.

[Sal_Bonaccorso]

I think you're hitting the pay dirt.

We are getting Ipsec Traffic.

Remember we used the Cloud formation template from Checkpoint to build the entire VPC and the Firewall so we assumed it built everything it needed.

The Cloud formation asked us for an External IP and and Internal IP Subnet.  

For this example Lets say my external is 10.60.90.0/24 and my internal is 10.60.10.0/24.

I also have another subnet in the VPC for some instances and they are on 10.60.11.0/24

So eth0 has an IP allocated 10.60.90.x and eth1 has a 10.60.10.x address.  The eth0 also has the EIP assigned to it.

Based on your reply I updated the routing table with 2 new entries.

Now lets say my corporate office we are connected to via VPN has an IP range of 10.10.0.0/24, I can ping a server in that IP space now.  But I cannot ping a server by name, even though the DNS of the AWS instance is set to the IP address of the server on the corporate side. I also cannot get out to the internet on the server in AWS.

The server at the corporate office can ping the AWS server by name, and by IP.

When I go to change the Network interface 2 issues.  Spoofing is going crazy, i just set it to detect, and In order for all this to work, I have to set both interfaces to Internal, which is not true. I have messed around with all types of combinations, eth0, External, goes to DMZ, Internal, Goes to DMZ, etc etc... nothing really works well and none really get rid of the spoofing alerts, even when I exclude all the subnets in the "Don't check these subnets", which I can only do when it is set to Internal.

So now what?

[PhoneBoy]

The reality is that your eth1 interface should have a route for all the subnets in your VPC (even ones you're not using).

Assuming your VPC is 10.60/16, a single route on the vSEC instance to 10.60.10.1 should cover current and future subnets.

Your existing route to 10.60.11/24 won't work because the next hop should be 10.60.10.1. 

Your anti-spoofing configuration should look something like this:

• eth0: External, but exclude the subnet 10.60.90.0/24 (you mark this as "don't inspect traffic from" in R80+, there's a similar setting in earlier versions)
• eth1: Internal (anti-spoofing should contain entire VPC space, so 10.60/16)

If the vSEC instance isn't able to resolve DNS correctly across the VPN, it may be that your encryption domain does not include the IP address of the vSEC instance. 

If your server in the VPC can't access the Internet, most likely you have not configured routing and NAT rules correctly.

I would encourage you to review the Getting Started Guide, which should cover that.

Note the NAT rule will be configured to hide the traffic behind the private eth0 IP (not the public Elastic IP).

[PhoneBoy]

I'm not sure I understand.

It would be really helpful if you posted a simplified diagram showing the various components and the traffic flows you are having issues with.

Are you trying to use the vSEC gateway in AWS for all ingress/egress traffic between your central office and the Internet?

If this is what you're trying to do, remember that you pay Amazon per-gigabyte of data transferred (whether over VPN or not).

Such a configuration could get expensive fairly quickly.

Are you terminating the VPN from your Central Office on the vSEC instance or terminating it on the VPN endpoint in AWS?

It makes a difference in terms of what the configuration would be.

In general, routing needs to be established in two places:

• At the Central Office side (to ensure you can route to the VPC)
• Inside the VPC (each subnet in AWS has its own routing table that will need to be configured with the appropriate next hop for each subnet).

If you're trying to reach the Internet (whether from your Central Office or your VPC), you will need to configure a rule similar to what is described in here: Secure outgoing Internet connections for VPC Instances in AWS.

If you want to expose the server in the VPC to the Internet (e.g. it's a server), check the vSEC Gateway for Amazon Web Services Getting Started Guide.