- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- Re: Site2Site VPN from Checkpoint to Checkpoint be...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Site2Site VPN from Checkpoint to Checkpoint behind another Checkpoint
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will check your hint and come back. Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please also consider publishing your question in the appropriate board - S2S VPN is not Remote Access 😉
Maybe PhoneBoy can move it ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also did you allow port 4500 (NAT-Travesal) through the external gateway?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!