NAT configuration for a Networks (Not) Connected to the Firewall

[mkopcic]

Hello!

This is the scenario and configuration that works on 8.0.3. It is implemented in our company.

Servers on public_dmz have public addresses and access Internet with that addresses. Only server with address 2.2.2.10 needs to be translated to 3.3.3.10 in both directions.

2.2.2.10 -> 3.3.3.10

Servers from private_dmz are published on the Internet using address from the address space used for public_dmz 2.2.2.0/24. They are using the same addresses when they are accessing Internet.

For example: 10.10.10.20 -> 2.2.2.20

Hosts from LAN are published on the Internet using address from the address space 2.2.2.0/24. They are using the same addresses when they are accessing Internet.

For example: 172.16.10.100 -> 2.2.2.100

One server from LAN has to be destination translated to 1.1.1.3.

192.168.3.3 -> 1.1.1.3

Basic routing

ISP configured routes for 2.2.2.0/24 and 3.3.3.10/32 pointing to the PAN (1.1.1.2).

PAN has default route pointing to the 1.1.1.1.

Routes on PAN for LAN networks are pointing to the 172.16.1.2.

Layer3 switch has default route to the 172.16.1.1.

NAT rules configuration

NAT for server 2.2.2.10. Bi-directional NAT doesn’t work. Separate source and destination NAT rules must be configured.

Source NAT:

Source zone: public_dmz

Destination zone: Internet

Destination interface: Eth1/1

Source IP: 2.2.2.10

Destination IP: any

Source translation static: 3.3.3.10

Destination NAT:

Source zone: Internet

Destination zone: public_dmz

Destination interface: Any

Source IP: any

Destination IP: 3.3.3.10

Destination translation: 2.2.2.10

NAT for server on the private_dmz. Bi-directional NAT doesn’t work. Separate source and destination NAT rules must be configured.

Source NAT:

Source zone: private_dmz

Destination zone: Internet

Destination interface: Eth1/1

Source IP: 10.10.10.20

Destination IP: any

Source translation static: 2.2.2.20

Destination NAT:

Source zone: Internet

Destination zone: private_dmz

Destination interface: Any

Source IP: any

Destination IP: 2.2.2.20

Destination translation: 10.10.10.20

NAT for the first server on the LAN. Bi-directional NAT doesn’t work. Separate source and destination NAT rules must be configured.

Source NAT:

Source zone: trust

Destination zone: Internet

Destination interface: Eth1/1

Source IP: 172.16.10.100

Destination IP: any

Source translation static: 2.2.2.100

Destination NAT:

Source zone: Internet

Destination zone: trust

Destination interface: Any

Source IP: any

Destination IP: 2.2.2.100

Destination translation: 172.16.10.100

NAT for the second server on the LAN.

Destination NAT:

Source zone: Internet

Destination zone: Internet

Destination interface: any or Eth1/1 (works with both settings)

Source IP: any

Destination IP: 1.1.1.3

Destination translation: 192.168.3.3

NAT routing

/32 for public address used in destination NAT, /32 routes must be configured. For ONLY source NAT, these routes don’t have to be configured.

For server in public_dmz

Destination: 3.3.3.10/32

Interface: Eth1/2

Next hop: None

For server in private_dmz

Destination: 2.2.2.20/32

Interface: Eth1/3

Next hop: None

For the first server on LAN:

Destination: 2.2.2.100/32

Interface: Eth1/4

Next hop: None

Security rules configuration

For server in public_dmz

Source zone: Internet

Destination zone: public_dmz

Source IP: Any

Destination IP: 3.3.3.10

Destination applications: web-browsing, ssl

Action: Allow

For server in private_dmz

Source zone: Internet

Destination zone: private_dmz

Source IP: Any

Destination IP: 2.2.2.20

Destination applications: web-browsing, ssl

Action: Allow

For the first server in LAN

Source zone: Internet

Destination zone: trust

Source IP: Any

Destination IP: 2.2.2.100

Destination applications: web-browsing, ssl

Action: Allow

For the second server in LAN

Source zone: Internet

Destination zone: trust

Source IP: Any

Destination IP: 1.1.1.3

Destination applications: web-browsing, ssl

Action: Allow

Global permit rules for zones:

Source zone: public_dmz

Destination zone: Internet

Source IP: 2.2.2.0/24

Destination IP: Any

Destination applications: web-browsing, ssl

Action: Allow

Source zone: private_dmz

Destination zone: Internet

Source IP: 10.10.10.0/24

Destination IP: Any

Destination applications: web-browsing, ssl

Action: Allow

Source zone: tust

Destination zone: Internet

Source IP: 172.16.0.0/16, 192.168.0.0/16

Destination IP: Any

Destination applications: web-browsing, ssl

Action: Allow

[reaper]

Hi @mkopcic

pretty good config

Your inbound NAT rules, however, are incorrect. NAT zones are determined pre-NAT based on the routing table, so inbound connections to 3.3.3.10 should be internet to internet because 3.3.3.10 also lives on the external interface from the firewall perspective

i'd recommend attaching the 3.3.3.10 IP on the external interface (not sure if you did that, the graph doesn't show it) as secondary IP, this makes management a bit easier and prevents accidents, plus you can then use 'dropdown' options where applicable (and will fix bi-directional)

If possible i'd also recommend attaching 2.2.2.0/24 to the external interface and provisioning your public DMZ with private IP addresses, this is a little more secure as you control not only security policy but NAT translation, and this will allow other segments to benefit more easily from this address pool without creating tricky U-Turn NAT because you use an IP that physically belongs to an internal interface on 2 different and unrelated (internet + privdmz) interfaces

Check out the Getting Started: Network Address Translation (NAT) article + tutorial video 🙂

and the How to Configure U-Turn NAT article + tutorial

[mkopcic]

Thank you for your suggestions.

You wrote:

"Your inbound NAT rules, however, are incorrect. NAT zones are determined pre-NAT based on the routing table, so inbound connections to 3.3.3.10 should be internet to internet because 3.3.3.10 also lives on the external interface from the firewall perspective

i'd also recommend attaching the 3.3.3.10 IP on the external interface (not sure if you did that, the graph doesn't show it) as secondary IP, this makes management a bit easier and prevents accidents, plus you can then use 'dropdown' options where applicable (and will fix bi-directional)"

This configuration just didn't work. After 3-4 hours of troubleshooting and stubbornly following Palo's documents, I quitted and followed my common sense. Few days after we had similar scenario at the customer’s Palo (version 7.1), and colleague first configured Internet for source and destination zones, and that configuration didn’t work.   

We also tried with secondary IP address on Internet interface and also it didn’t work.

"If possible i'd also recommend attaching 2.2.2.0/24 to the external interface and provisioning your public DMZ with private IP addresses, this is a little more secure as you control not only security policy but NAT translation, and this will allow other segments to benefit more easily from this address pool without creating tricky U-Turn NAT because you use an IP that physically belongs to an internal interface on 2 different and unrelated (internet + privdmz) interfaces"

This is not an option.  In one day all servers from public DMZ will be migrated to private DMZ, but for now design is like that. In my experience, NAT is not security feature (it is just a way to hide private addresses and preserve public). If you open HTTP to the server and don’t harden it, it doesn’t matter if server has public or private IP address. Good rules on FW from dmzs to inside network are much more important. HTTP is UFBP (Universal Firewall Bypass Protocol) 🙂 🙂

This is also example how NAT can be configured in unusual network design.

Kind regrds,

Maja