IPSec connection up but services don't work over it

[Rafael_Ochoa]

Hello. I'm configuring a site-to-site VPN using Azure resources (between a checkpoint IAAS Single Gateway and an Azure Virtual Network Gateway). 

The VPN connection is up (the connection in Azure appears as 'Connected' and reports some traffic), and I can see in the Checkpoint logs that packages are being decrypted but I'm not receiving an answer for either ping, http or ssh from one network to another.

I attached a screenshot of what I see in the checkpoint logs. I'll appreciate if you let me know what else can I attach to diagnose the problem.

Thanks in advance for your help!

[PhoneBoy]

Not clear what end of the VPN you are initiating from (and thus which end might be failing).

Might help to use tcpdump or similar to see if packets are entering/exiting the gateway as expected.

[Rafael_Ochoa]

I'm creating the connection in the Azure Virtual Gateway. In the previous message, I attached the logs of the Checkpoint, were you can see the Keys are being correctly installed, and some traffic is being decrypted at the Checkpoint (but I'm not receiving an answer in the device connected to the Azure Gateway).

[PhoneBoy]

If you're seeing some traffic being decrypted on the Check Point, it suggests that the traffic is originating from the Azure Virtual Gateway.

Is that correct?

In which case, you should be able to see if unencrypted traffic leaves the Check Point gateway with tcpdump.

[Rafael_Ochoa]

If I run tcpdump I see a lot of things going on in the console, is there a way to filter that?

Anyway, I have updates: I found a mistake I made yesterday, because it's a Route Based VPN and I was defining VPN domains as it was Policy Based. 

I fixed it today, using empty groups to define VPN Domains, adding a VPN Tunnel Interface in the WebUI and adding a static route for that interface and updating the topology of the Gateway Object.

I'm using Smart View and it says the tunnel is UP, and there are encrypted/decrypted packages (about 2 million packages for each one in the accumulative account). Whenever I send a ping or a ssh through the tunnel (from Azure to Checkpoint network) I can see it in the logs with the action "VPN routing", but if I send it from Checkpoint to Azure I can't see anything in the Checkpoint logs. 

But that ping or ssh command is not getting an answer even when it appears in the log (it times out all the time).

[PhoneBoy]

tcpdump does offer filtering options.

Some basics here: tcpdump tutorial 

Basically you'd be filtering on the original source/destination.

You may also want to check the routing table on the gateway to ensure that the appropriate subnets are being routed through the tunnel interface.

[Rafael_Ochoa]

Thank you Dameon.

I'm using tcpdump -i vpnt1, to catch the traffic on the tunnel and I'm not getting any results. I can see the tunnel is still up in SmartDashboard. I suppose the traffic on a Route Based VPN should appear there, am I right?

When I used tcpdump dst (public IP address of the Azure gateway) and I try to connect SSH from a VM in the Azure Netowrk to a virtual machine in the Checkpoint network (which is my main purpose), I can see the following:

22:42:57.966502 IP checkpoint.ipsec-nat-t > 137.117.45.100.ipsec-nat-t: UDP-encap: ESP(spi=0x6b970124,seq=0xb21), length 96

[PhoneBoy]

That looks like an encrypted packet going from the Check Point to the remote end.

I thought this traffic was coming from the remote end through the Check Point?

[Rafael_Ochoa]

Thank you again Dameon Welch-Abernathy‌ . I was able to made some more complete tests using tcpdump, which I summarize here (all the time, the tunnel is shown as UP in Smart Monitor, and the connections is either Connected or Succeeded in Azure, showing some traffic).

1.- tcpdump host (public IPof my Azure gateway) without sending any commands:

17:57:56.334561 IP checkpoint.isakmp > 137.117.45.100.isakmp: isakmp: phase 2/others ? #37[]
17:57:58.334778 IP 137.117.45.100.isakmp > checkpoint.isakmp: isakmp: phase 2/others ? #37[]

This keep appearing over and over

2.- tcpdump host (public IP of my Azure gateway) sending an SSH command from a VM in the Azure network to a VM in the checkpoint network:

17:59:22.248027 IP checkpoint > 137.117.45.100: ESP(spi=0xd4e6b1f0,seq=0x7b), length 100
17:59:22.249553 IP 137.117.45.100 > checkpoint: ESP(spi=0xb1a8503e,seq=0x93), length 100
17:59:22.249660 IP checkpoint > 137.117.45.100: ESP(spi=0xd4e6b1f0,seq=0x7c), length 100
17:59:22.251467 IP 137.117.45.100 > checkpoint: ESP(spi=0xb1a8503e,seq=0x94), length 100

This appears until I kill the ssh command, and then I keep watching the same output of test 1.

I didn't get an answer for either ssh or ping communication.

3.- tcpdump host (public IP of my Azure gateway) sending an SSH command from a VM in the checkpoint network to a VM in the Azure network:

18:04:10.204280 IP 137.117.45.100.isakmp > checkpoint.isakmp: isakmp: phase 2/others ? #37[]
18:04:10.206465 IP checkpoint.isakmp > 137.117.45.100.isakmp: isakmp: phase 2/others ? #37[]
18:04:12.211492 IP 137.117.45.100.isakmp > checkpoint.isakmp: isakmp: phase 2/others ? #37[]
18:04:12.213526 IP checkpoint.isakmp > 137.117.45.100.isakmp: isakmp: phase 2/others ? #37[]

I didn't get an answer for either ssh or ping communication.

I'm trying to establish a route based VPN between a checkpoint Iaas single gateway R80.10 (in Azure) to an Azure Virtual Network Gateway. 

I configured VPN domains as empty groups in the checkpoint, configure the vpnti and a static route through it.

I'm using the default encryption and data integrity value for the Azure gateway in IKE V2.

If I run tcpdump -i vpnt1, it doesn't capture any packets.

[PhoneBoy]

It looks like we see return encrypted traffic but…not unencrypted traffic.

I recommend opening a TAC case so we can do more detailed Troubleshooting with the experts.

[Mark_Mitchell]

From the Check Point side have you attempted to complete a VPN debug and analyse the .elg or the xmll file (if IKEv2) file? The VPN debugs are normally pretty decent and point you in the direction where the issue is. 

Also do you get the same results regardless whether SecureXL is on or off?

SK: How to generate a valid VPN debug, IKE debug and FW Monitor 

I've completed the process many times and had really good success with it.

[GG27]

I had the same problem with Azure.

During my investigation I found the SXL was the root cause and disabling it by "fwaccel off" on the gateway, the connection establishes between the edge servers .

With the TAC (about 1 month and half of debugs) I had the solution and it worked.

The solution was change the encryption parameter in phase 2 to AES-256 (no AES-GCM-256).

[GG27]

Sorry ... in addition to previous post

MGMT ver R80.10 last jumbo take

GW ver R80.10 last jumbo take

[Rafael_Ochoa]

I was finally able to solve the problem. My static route was wrongly configured and it obiously prevented the traffic to be correctly routed.

So, to summarize the solution:

- It was a RoutedBased IPSEC VPN, so I had to configure empty groups as VPN Domain in both gateways.

- I had to create a VPN tunnel. I created as numbered and used the public IPs of both gateways to define it. Then I had to update the topology in the gateway.

- I had to configure a static route to redirect all traffic to remote local network through the vpn tunnel.

- To define the IPs of the gateways I could either use the public IP (and selected main address in VPN link selection) or the private IP (and selected statically NATed address in VPN link selection to the public IP).

- All of the cryptographic parameters should match.

- I had to create an Access Policy to allow traffic across the VPN (the way it worked was defining source and destination to the address space of both networks and leavin Any as VPN). For some reason, checking the box 'Accept all encrypted traffic' in the VPN community didn't do the job (I thought if I checked that box I didn't need an access policy).

- The Machines you want to have access to should be connected to interfaces defined in the topology as internal. I think this could be some stupid confusion I had, but it made me waste a looooot of time.

Thank you all for your kind help, and I hope this post could be useful for some other newbies (like me) in the future

[Dami]

Hello, 

Please I am curious about the access policy, you mentioned you used Any under VPN column, I thought we are meant to include the VPN community under the VPN column. 

How does the IPSEC rule apply to the traffic if you used "Any" under VPN column?

Thanks in anticipation 

[Timothy_Hall]

"Any" in the VPN column of a rule means that it can match encrypting traffic, decrypting traffic, or cleartext traffic.  Including an actual VPN community in the VPN column ensures that the rule will only be matched if the source, destination, and service all match AND that the traffic is encrypting into a VPN tunnel of that specific community or decrypting from a tunnel of that specific community, based on the VPN domains or routing in/out of a VTI.  Traffic going to/from a different VPN community or going in the clear will not match that specific rule even if the source, destination, and service all match.

So you don't really have to change the VPN column from the default of Any to have it match traffic involved with a VPN.  However security best practices dictate that it is a good idea to explicitly set a VPN community in the VPN column, which ensures that traffic is being matched to the rule and handled the way you expect (i.e. being encrypted or decrypted and not just being sent in the clear where it is vulnerable to eavesdropping).  The VPN column is NOT how traffic is deemed to be "interesting" (to borrow a Cisco term) to a particular VPN tunnel and requiring encryption.  The VPN domains or routing into a VTI is what makes that "interesting traffic" determination for a Check Point firewall.

[Dami]

Thank you Timothy,

Appreciate the clarification.
This means in a demo setup if I have an explicit rule to permit all traffic ( changing the clean up rule from "drop" to accept). I do not need a separate rule in the rule base for VPN traffic to work as long as the VPN community and VTIs are defined for the Gateways involved.