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

Reply
Highlighted
L2 Linker

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

Hello!

 

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

 

 

NAT_slika.jpg

 

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

Highlighted
L7 Applicator

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

reaper - PANgurus.com
Find my book at https://www.amazon.com/dp/1789956374
Highlighted
L2 Linker

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

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!