NAT Loopback configuration problem in R80.10

I have problem to configure a hairpin NAT (NAT Loopback) on my system.

I have a local Lan that is 192.168.0.0/24

On the wan side I have xx.xx.xx.107 that is where all “normal” traffic is using without any problem.

I have xx.xx.xx.122 where I NAT https to an internal server.

I can access the https NAT server from an external IP

When I try to access the https external IP from an internal IP on the Lan side (192.168.0.0/24) it is not possible to access the service. In the log file for the access control policy I get an entry that the client is going out to access the external ip. I do not get a log entry for denied or allowed for the access back to the https service.

If you are accessing https NAT server from locally, why you are doing such lengthy process. It should be within your LAN or should be between DMZ to LAN. Means connectivity is between your private IPs, No need to do NAT.

According to Hairpin NAT SK you have to create two rules when the traffic is originated from the LAN.

The important thing to returning traffic is the translated source, that shoud be the gateway address. You must create a new host object with the IP address of the gateway (if you have the LAN address as IP of the main GW object, it should work without create a new one) on the translated interface (i assumpt this is the same 192.168.0.0/24 LAN):

No.

OriginalSource

OriginalDestination

OriginalServices

TranslatedSource

TranslatedDestination

TranslatedServices

Install On

1

LOCAL LAN192.168.0.0/24

PUBLIC SERVER

Extern .122

https

GW LOCAL LAN IP

192.168.0.1

SERVER PRIVATE IPDemoLEMiCCE

= Original

SecurityGatewayobject

2

SERVER PRIVATE IPDemoLEMiCCE

LOCAL LAN192.168.0.0/24

https

PUBLIC SERVER

Extern .122

= Original

= Original

SecurityGatewayobject

You have to put the rules at the top of your NAT rulebase, before Automatic Hide NAT and Manual lower rules to work.

I have implemented your suggestion in my system and i do not get any change in behaviour.

I still get the connection from the internal network when using the WAN address.

I have performed a tcpdump with help of "fw monitor -e "accept;" -o /var/log/fw_mon.cap" in the expert mode and in the cap file i get the connection attempt from the internal network to the internal fw address.

I do not get any traffic back to the internal network from the fw in the cap file. When i perform the same cmd using external machine accessing the service i get the complete tcp flow.

Have you reviewed the connections table in case there is an old session without NAT for this? Sometime ago I had that problem and had to clear the specific connection (clear all connections table also works).

The connection on fw monitor should be seen as something like this if the LAN users are pointing to external address to access the server (dont forget to disable SecureXL):

[internal_interface.i] 192.168.0.0/24:xxxxx --> Extern .122:443

[internal_interface.I] 192.168.0.0/24:xxxxx --> DemoLEMiCCE:443

[internal_interface.o] 192.168.0.0/24:xxxxx --> DemoLEMiCCE::443

[internal_interface.O] 192.168.0.1:xxxxx --> DemoLEMiCCE:443

The following conditions are assumed on this scenario:

- The server DemoLEMiCCE is on the same 192.168.0.0/24 subnet.

- The address on the gateway object is 192.168.0.1 or a new object with this address was created.

- The first manual NAT rule for Source Translation of the LAN is working as Hide NAT.

I dont think this is a routing problem because you have directly connected the LAN and external interfaces, also Translate destination on client side is enabled (avoiding you to create a static route).

Can you attach an screenshot of your manual NAT rules for this?

Also if you can make an fw monitor capture filtering the involved hosts (external and internal addreses) like this one:

You have created a network object with /32 mask, is the most probably cause for wrong translation.

The easiest way to do this is create a new host object and put the gateway IP on the 192.168.0.0/24 subnet. After this, you configure it as Translated Source Right click --> NAT Method --> Hide so this way all the subnet is nated as hide with gateway address.

If you have configured the gateway with the LAN address like this:

You should be able to use gateway object as translated source (hide also) without create the host object mentioned above.

This is one of the many reasons why you should NEVER setup your Internet accessible servers in the normal LAN.

Always use a DMZ on the FW, that way you control the traffic from that server to the rest of the network as well. This scenario is just one of the issues we see quite a lot of times with our customers that do not use a DMZ Network.

I don't know if I made things better or worse, but after looking at the original article, the R77 part didn't look right to me. So I flagged it and got this back from Check Point:

Hello Michael Lawrence,

SecureKnowledge solution ID: sk110019 and Title: "How to configure NAT Loopback (Hairpin NAT / NAT Reflection) on Check Point Security Gateway" has now been edited based on your feedback.

Your feedback was:

------------------

The R77 rules don't look right to me. I'll use rule 2 in the last table for reference. In this case, since the GW is leaving the source address at the original IP of 192.168.1.10, the server will reply to that address (destination will be 192.168.1.10), causing the problem described at the top of the article where the server will try to send the packet directly to the private host (since they are both on the same network) and the host will reject it because it is expecting a packet from 1.1.1.1. Am I missing something?