Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

L3 deployment with dynamic IP and DMZ (NAT and PBF required?)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

L3 deployment with dynamic IP and DMZ (NAT and PBF required?)

L3 Networker

Dear all,

I'm trying to move from my initial vWire deployment to L3 in order to get rid of my SSG5. Later on I'll also get rid of my SA-2000.

Current layout:

ISP (dynamic IP) - PA vWire - SSG5 - PA vWire - Intranet

                                                |

                                           SA-2000

I'm clear how to set up NAT to access the Internet from my internal network.

What I'm a bit unclear is how to set up my DMZ.

Currently the SSG5 forwards all traffic incoming on port 443 to the SA. App filter in place on the external vWire to allow only Active Sync and Secure-access including inbound decryption.

In my understanding I need to configure PBF to forward e.g ingress traffic arriving at the dynamic untrust interface on port 443 to the DMZ interface, correct?

I assume this also means destination NAT (bi-directional?). Can I still filter by application? Some notes mention that PBF and app filter don't work together.

Is there a way to change the port too?

Assuming I want to keep 443 for future remote access via the PA, can I configure a way to translate untrust IP/444 to DMZ IP/443?

Regards,

     Andreas

1 accepted solution

Accepted Solutions

L3 Networker

Hello Andreas,

You are correct. You do need a route on the firewall pointing the dynamic, untrust IP address towards the DMZ interface. If you are only expecting 443 traffic on this dynamic address, then you could accomplish this with just a static route. If you are expecting to receive 443 and other services on this IP address however, then you do need a PBF policy.

You can still filter by application and you could use a bi-directional NAT as well.

I've not encountered any problems with PBF and app filter so I cannot comment on that, but they are designed to work in harmony if configured correctly.

For your last question, yes, you can translate the destination port from your untrust traffic(444) to a different port(443) using NAT.

The NAT statement would look something like the following:

444-to-443.PNG.png

Note that the NAT policy permits Untrust to Untrust but the security policy needs to permit Untrust to DMZ.

See the following document for more information regarding NAT on the Palo Alto.

https://live.paloaltonetworks.com/docs/DOC-1517

Regards,

tasonibare

View solution in original post

2 REPLIES 2

L3 Networker

Hello Andreas,

You are correct. You do need a route on the firewall pointing the dynamic, untrust IP address towards the DMZ interface. If you are only expecting 443 traffic on this dynamic address, then you could accomplish this with just a static route. If you are expecting to receive 443 and other services on this IP address however, then you do need a PBF policy.

You can still filter by application and you could use a bi-directional NAT as well.

I've not encountered any problems with PBF and app filter so I cannot comment on that, but they are designed to work in harmony if configured correctly.

For your last question, yes, you can translate the destination port from your untrust traffic(444) to a different port(443) using NAT.

The NAT statement would look something like the following:

444-to-443.PNG.png

Note that the NAT policy permits Untrust to Untrust but the security policy needs to permit Untrust to DMZ.

See the following document for more information regarding NAT on the Palo Alto.

https://live.paloaltonetworks.com/docs/DOC-1517

Regards,

tasonibare

Hello tasonibare,

thanks a lot for your answer.

It turned out to be simpler than I expected.

All I needed was a NAT rule similar to what you showed without any PBF rules. In addition I just had to add the DMZ zone as a source zone to the outgoing source NAT and everything worked as expected. (OK, almost. I lost a couple of hours before I figured out that my DynDNS IP used as a FQDN address object was wrong).

Regards,

     Andreas

  • 1 accepted solution
  • 2540 Views
  • 2 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!