NAT Loopback configuration problem in R80.10

[Kristian_Nyquis]

Hi

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.

I have been reading the https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

But I do not it to work.

The config I have in my NAT rules is according to the attached picture. What is it that I am missing?

Is my NAT rules in the incorrect order?

[Gaurav_Pandya]

Hi Kristian,

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.

[Kristian_Nyquis]

Hi Gaurav,

Unfortunately i need to use the WAN IP in this case to get full functionality on the webpage.

//Kristian

[Gaurav_Pandya]

Ok Kristian,

In that case, you can check the Kenny's Suggestion.

Hope you have different subnet for LAN as well as for servers (DMZ).

[KennyManrique]

Hello Kristian,

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.	Original Source	Original Destination	Original Services	Translated Source	Translated Destination	Translated Services	Install On
1	LOCAL LAN 192.168.0.0/24	PUBLIC SERVER Extern .122	https	GW LOCAL LAN IP 192.168.0.1	SERVER PRIVATE IP DemoLEMiCCE	= Original	Security Gateway object
2	SERVER PRIVATE IP DemoLEMiCCE	LOCAL LAN 192.168.0.0/24	https	PUBLIC SERVER Extern .122	= Original	= Original	Security Gateway object

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

Regards.

[Kristian_Nyquis]

Hi Kenny,

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.

Any other setting that i need to perform to get this to work?

//Kristian

[KennyManrique]

Hi Kristian

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.

   - The option NAT --> Manual NAT Rules --> Translate destination on client side is enabled in Global Properties.

Regards

[Kristian_Nyquis]

Hi  Kenny,

I have now cleared all connections table with out any change.

Yes i do have the  "NAT --> Manual NAT Rules --> Translate destination on client side " set to enable.

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

That is correct

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

That is correct

   - The manual NAT rule for Source Translation is working as Hide NAT.

That is correct

Can it be a routing table problem?

//Kristian

[KennyManrique]

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:

   fw monitor -e "(net(192.168.0.0,24) and host(Extern.122_IP_ADDRESS)) or (net(192.168.0.0,24) and host(DemoLEMiCCE_IP_ADDRESS)), accept;"

Regards.

[Kristian_Nyquis]

I get the following:

[vs_0][fw_0] eth5:i[52]: 192.168.0.6 -> xxx.xxx.xxx.122 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000
[vs_0][fw_0] eth5:I[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000
[vs_0][fw_0] eth5:o[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000
[vs_0][fw_0] eth5:O[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000

when running:

fw monitor -e "host(192.168.0.6) or host(192.168.0.31) or host(xx.xx.xx.122) or host(192.168.0.252) and port(443), accept;"

I did re-run my wireshark on 192.168.0.6 and 192.168.0.31 (DemoLEMiCCE)

Now I get traffic between these two hosts on port 443 but the web browser is not is not displaying the page.

In the attachment is a tcpdump from the client machine .6

Bellow is my NAT rules

[KennyManrique]

It seems you're not translating the source of 192.168.0.0/24 LAN

According to capture, packet is leaving the interface with original address 192.168.0.6:

[vs_0][fw_0] eth5:i[52]: 192.168.0.6 -> xxx.xxx.xxx.122 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000
[vs_0][fw_0] eth5:I[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000
[vs_0][fw_0] eth5:o[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000
[vs_0][fw_0] eth5:O[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=14798
TCP: 56715 -> 443 .S.... seq=8b9cf060 ack=00000000

On your NAT rule number 1 Translated Source is missing, you need to put here the object with the gateway address (for your capture I think is 192.168.0.252) and configure as hide nat (Right click --> NAT Method --> Hide)

Otherwise, your server "thinks" this is local traffic due to the 192.168.0.6 hosts is in its same subnet and does not need to send the reply traffic to default gateway.

Regards.

[Kristian_Nyquis]

Did that and now i get 192.168.1.2 as the return address

[vs_0][fw_1] eth5:i[52]: 192.168.0.6 -> xx.xx.xx.122 (TCP) len=52 id=31345
TCP: 56818 -> 443 .S.... seq=48a67142 ack=00000000
[vs_0][fw_1] eth5:I[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=31345
TCP: 56818 -> 443 .S.... seq=48a67142 ack=00000000
[vs_0][fw_1] eth5:o[52]: 192.168.0.6 -> 192.168.0.31 (TCP) len=52 id=31345
TCP: 56818 -> 443 .S.... seq=48a67142 ack=00000000
[vs_0][fw_1] eth5:O[52]: 192.168.1.2 -> 192.168.0.31 (TCP) len=52 id=31345
TCP: 56818 -> 443 .S.... seq=48a67142 ack=00000000

The translated source i was forced to create as a network ( the same type on original and translated)

Now the question is where does the 192.168.1.2 come from

[KennyManrique]

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.

Regards.

[Kristian_Nyquis]

I am not allowed to use the host object in this case:

Because on the Original source a network range is used and then that is also need on the translated source.

I have now created a network range according to the following:

Then it is possible to access the server.

[KennyManrique · Accepted solution]

You have not changed the NAT method to Hide, that's why you got an error about range size. Static NAT its trying to translate a /24 subnet to a /32, and this cant be done.

If you use a host object or gateway object and configure hide nat on nat rulebase, it will work.

Regards.

[Kristian_Nyquis]

That worked, thank you for your help.

I did miss that button for the nat method, i did only change it according to bellow:

[KennyManrique]

Great to hear it works!

When you configure NAT on the object, it goes straight to Automatic NAT rules for that object only (below your manual NAT rules).

For manual NAT rules, you need to specify the method for the translated object through right click.

BTW, thanks for the badge!

Regards.

[Kamil_Wisniews1]

Hello Kennry,

I have the same situation as Kristian_Nyquis but my gateway is a proxy server also.

If I create a manual NAT i don't see anything in logs and fw monitor is not showing connection to external address in proxy mode gateway. It shows only connection between host and proxy server address IP.

Next issue is that automatic static NAT translation enabled on host object works fine but when I  removed it and create manual NAT for this host object then NAT translation not occur and could not connect to web server.

Do you know maybe where will be the problem?

[Maarten_Sjouw]

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.

[Gaurav_Pandya]

Yeah. It is best security practice to separate Server-DMZ zone so that it can be easily managed and secured.

[MardoqueoRob]

hi Gaurav_Pandya If it were in this case to do NAT from LAN to DMZ, what would the rules be like?

[Octavian_Dragul]

You might have slipped a public ip in the 7:13 comment.

Regards,

Octavian 

[Michael_Lawrenc]

You could also try this for the first rule:

source  dest  x-source  x-dest

192.x   x.122   original   x.122(private) 

This basically says not to translate LAN traffic source, but to translate DMZ server destination.  Return traffic would come back and be translated via Kenny's second rule above just fine. 

[Michael_Lawrenc]

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?

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

To view this solution, go to https://supportcenter.checkpoint.com/supportcenter/LoginRedirect.jsp?toURL=eventSubmit_doGoviewsolut....