topic Re: NAT Loopback configuration problem in R80.10 in Firewall and Security Management

NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Tue, 02 Jan 2018 08:39:26 GMT

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=&solutionid=sk110019

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?

Re: NAT Loopback configuration problem in R80.10

Gaurav_Pandya — Tue, 02 Jan 2018 10:24:15 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Tue, 02 Jan 2018 11:24:50 GMT

Hi Gaurav,

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

//Kristian

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Tue, 02 Jan 2018 13:54:24 GMT

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

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

SERVER PRIVATE IP
DemoLEMiCCE

LOCAL LAN
192.168.0.0/24

https

PUBLIC SERVER

Extern .122

= 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.

Re: NAT Loopback configuration problem in R80.10

Gaurav_Pandya — Tue, 02 Jan 2018 15:03:01 GMT

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).

Re: NAT Loopback configuration problem in R80.10

Michael_Lawrenc — Wed, 03 Jan 2018 06:36:55 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Wed, 03 Jan 2018 12:39:01 GMT

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

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Wed, 03 Jan 2018 13:05:42 GMT

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

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Wed, 03 Jan 2018 14:08:54 GMT

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

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Wed, 03 Jan 2018 14:16:08 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Wed, 03 Jan 2018 14:38:44 GMT

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

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Wed, 03 Jan 2018 14:49:32 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Wed, 03 Jan 2018 15:08:21 GMT

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

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Wed, 03 Jan 2018 15:20:40 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Wed, 03 Jan 2018 15:33:06 GMT

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.

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Wed, 03 Jan 2018 15:43:41 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Kristian_Nyquis — Wed, 03 Jan 2018 15:52:03 GMT

That worked, thank you for your help.

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

Re: NAT Loopback configuration problem in R80.10

KennyManrique — Wed, 03 Jan 2018 15:59:22 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Maarten_Sjouw — Wed, 03 Jan 2018 19:22:44 GMT

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.

Re: NAT Loopback configuration problem in R80.10

Gaurav_Pandya — Thu, 04 Jan 2018 04:16:27 GMT

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