topic Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint in SASE and Remote Access

Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Wed, 28 Aug 2019 09:42:22 GMT

Hello Everybody

I have a strange problem nobody seems to have a solution for.

My Setup looks like

Checkpoint GW 80.30 ("DC-GW") -> Internet <- Checkpoint GW 80.30 ("CUSTOMER-GW" <- Checkpoint GW ("Solution-GW") 1430 most current FW

DC-GW has a public IP

Customer-GW has a public IP and NATs all traffic to the internet

Solution GW gets its IP by DHCP

My problem is the VPN Tunnel between Solution-GW and DC-GW Issue in detail: Solution GW can establish VPN Tunnel without any issue.

SA is created on both sites and a host behind the Solution GW can access ressources in Datacenter! But the Ressources in Datacenter cannot esstablish any connection to the same ressources in the Branch

BRANCH PC -> ICMP -> DATACENTER PC is ok
DATACENTER PC -> ICMP -> BRANCH PC is failing.

ON CUSTOMER-GW static NAT is built up:

Source - Dest - srv - trans Source - trans dest
DC-IP - Customer IP - any - original - SOL-GW-IP
SOL-GW-IP - DC-IP - any - Customer IP - original

Management Traffic between DC and SOL is no problem - fetching policy and changes works like charm.

My findings are:
Customer-GW is dropping all incomming IP0(0/0) packets because of missmatch in SA, when starting communication vom DC-GW. (On DC-GW packtes are encrypted as expected.) - which is in fact not wrong ; the Customer-GW has of curse no matching SA for this VPN Connection.

So the main question: How can I avoid the dropping of the IP0 packets on Customer FW and make sure these packets where forwarded as configured in the Static NAT? I do not have the possibility of a dedicated public IP for this. Thanks in advance Christian

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

Maarten_Sjouw — Wed, 28 Aug 2019 08:06:52 GMT

First, your post is very hard to read wihtout any formatting

On the issue, I think you need to check that the NATted IP should be added in the link selection source of the gateway object for the gw that is NATted. Make sure the IP's there are the real IP's the OTHER GW sees.

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Wed, 28 Aug 2019 09:40:09 GMT

My browser messed up with the formating, sorry for this.

I will check your hint and come back. Thank you!

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

G_W_Albrecht — Thu, 29 Aug 2019 07:58:33 GMT

Please also consider publishing your question in the appropriate board - S2S VPN is not Remote Access 😉

Maybe PhoneBoy can move it ?

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Thu, 29 Aug 2019 08:49:46 GMT

Hello,

there is no possibilty to set a public IP when the Gateway is configured as "Dynamic Address"

Is theire any option so the WAN Checkpoint VPN-KERNEL will ignore IP/0 (ESP) from specific IPs ? and forwards them to the inside Gateway ...

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

Maarten_Sjouw — Thu, 29 Aug 2019 09:05:15 GMT

Source IP address settings...
Also did you allow port 4500 (NAT-Travesal) through the external gateway?

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Thu, 29 Aug 2019 09:59:10 GMT

yes

Hello again,

for testing purpose i have built up an rule which allows everything between the internal GW and the DC Checkpoint.

VPN Tunnel is established without issues.
The point i do not understand is , the "client" initated connection throw the VPN is working fine, the DC initated connection does not work.

This is the reaction of the WAN Checkpoint when I start a ICMP from the DC to the LAN behind the 1430 Appliance using the VPN TUNNEL

The encapsulated "VPN Packet" is routed correct, because the WAN Checkpoint also has VPN Softwareblade enabled it drops all IP/0 packets which are not matched by its internal SA, SPI list.

Static Natting from the DC IP is configured but not taken into account. So the VPN Packet does not arrive at the 1430.

Strange part: Starting the ICMP behind the 1430 in direction to DC - I get stable responses.

Session inside the VPN initated in DC -> no connection possible WAN Checkpoint drops IP/0
Session inside the VPN initated from behind the DAIP 1430 -> packets are running seamless to DC and the response is working also fine

Some colleagues suggest using a dedicated pub-IP for the 1430 - but in the planned szeanrio this is not possible

Thanks for your help so far

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

Maarten_Sjouw — Thu, 29 Aug 2019 11:08:45 GMT

The Dedicated public NAT-IP might be your only option here, as the DC gateway will always try to open the connection in the other direction.
This will also allow you to make sure that all traffic is dropped at the right box, as 1400 series will work properly behind a NAT connection, but the is very slim that it will work in the way you did it with Hide NAT.

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

Wolfgang — Thu, 29 Aug 2019 11:11:31 GMT

Hello croessler,

I think there is something wrong in your configuration.

First of all you have to enable NAT-traversal and on "CUSTOMER-GW" you have to allow NAT-T like Maarten suggests.

This is important, without NAT-T you can't get the tunnel working for both directions.

If "Solution-GW" is defined with dynamic IP-address, you don't need any NAT for management and VPN on "CUSTOMER-GW".

All connections are initiated from the "Solution-GW".

If you forward any ESP/IKE/IPSEC-packet on "CUSTOMER-GW" you get the shown error.

Maybee this will help:

0. enable NAT-traversal on "Solution-GW" and "DC-GW"

1. define "Solution-GW" with dynamic address

2. don't define any NAT on "CUSTOMER-GW" with destination "Solution-GW" or if some other needed define only for special ports, not with any, not with IPSEC, not with NAT-T or other VPN related ports

2.1. you can do hide NAT on "CUSTOMER-GW" for "Solution-GW" , but don't do any static-NAT

3. create a rule accepting NAT-T on "CUSTOMER-GW"

4. define VPN-community with only "DC-GW" and "Solution-GW"

5. create a rule allowing the needed VPN traffic

6. To get the tunnel up a host behind "Solution-GW" has to initiate the tunnel first, if this does not occur you can't communicate from datacenter to branch

With dynamic address the "Solution-GW" fetches too his policy from management.

Wolfgang

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Thu, 29 Aug 2019 11:55:18 GMT

Hello Wolfgang,

thank you a lot for your Guide.
Following these steps does not change the behavior of the "Customer GW".

I guess I should create official ticket to get a information if its possible in general...

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

Wolfgang — Thu, 29 Aug 2019 12:49:58 GMT

Yes, what you are trying to do is possible.

We had this running with third party device and with Check Point gateway at the place of your "Customer GW".

What is shown in the log of "Customer GW", are there any NAT-T packets ? Are there any logs ?

One question...

You wrote "Solution-GW" get the external IP via DHCP. Is this IP included in the encryption domain of "Customer GW" ?

These should be excluded.

Wolfgang

PS: Snip from VPN documentation....

Check Point VPN clients and SMB appliances (600/700/1100/1200R/1400/Edge), will initiate a negotiation with NAT-D payload, so NAT-T can be agreed on. However, Security Gateways currently support responding to negotiation with NAT-D payload, but do not initiate NAT-D themselves (The practical note is that if you have SMB appliance behind NAT - it should be behind Hide NAT, so that the Central Gateway cannot initiate IKE connections to it, rather the Central Gateway would have to wait for the SMB appliance to start the IKE negotiation).

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Mon, 02 Sep 2019 12:43:22 GMT

Hello Everybody,

i figured out a solution i do not understand in detail.

I just created a ip-range NAT on the "Solution-GW".
When I do an icmp / http or whatever to the NAT-IP - the ressources behind the Solution GW answer without any issue.

DCSYSTEM -> ICMP TO NAT-NET -> 1430er translates NAT-NET to real IP -> connection is fine

DCSYSTEM -> ICMP TO real IP -> packet does not arrive at 1430

If anybody understand whats happend, everybody here in the office would be very happy to get to know.

So I guess i will take my luck an look forward to implement the designed solution on multiple occasions.

Thanks for your input and hints so far.

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

Wolfgang — Mon, 02 Sep 2019 19:14:05 GMT

I think it‘s to complex to understand what‘s going on.

Without more details about the gateway configuration, the vpn community, the NAT it‘s hard to say why it works.

Maybee you have an ipsec-tunnel between the wrong gateways and the new NAT rules let the packets flow.

Wolfgang

Re: Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint

croesler — Tue, 03 Sep 2019 06:05:34 GMT

Hello Wolfgang,

due to the fact, the DC and the Solution GW are the only Gateways in the Management i am 100% sure to have the correct systems participating in the community. using IKE2 for tunnel.

Solution GW has DHCP on WAN port and is configured as DAIP.

I have configured a dedicated VPN community with "permanet tunnels" with tunnels per subnet.

DC Gateways has one network in the encryption domain 10.255.255.255.0/24

and the

Solution GW has two nets in its enc_dom: -10.0.1.0/24 (aka. masking net) -> just for natting

-172.16.42.0/25 (aka Solution Net)

To get a connection von DC to Solution I had to built up Static NATting on Solution GW for

SRC - DEST - service - xlatesrv - xlate dest - xlate src

Any - 10.0.1.0/24 - any - original - 172.16.42.0/24

172.16.42.0/24 - any - any - 10.0.1.0/24 - original

So in the end is pretty basic stuff from a VPN perspective.

But for now anything i want to got working is working, so there is no need to bother further with this.

Thanks again for all your help!!