NAT and security policies

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

NAT and security policies

L2 Linker

Hi all.  I am trying to setup a ADFS environment in our network.  The actual ADFS server is located in the internal LAN, and the ADFS Web Application proxy is reside in the DMZ; internal LAN and DMZ is in a different VLAN.  

The goal is to send user authentications (orginiated from the Internet) to the ADFS web application proxy, and from there it communicate with the ADFS server in the internal LAN over port 443.

I've created the NAT rule in the PA firewall, and pointed it to the ADFS WAP server.

Also created the security policies to allow port 443 communication between the ADFS WAP and the ADFS server.

However, this where I am having the problem.

The ADFS WAP and the ADFS server failed to communicate with each other over port 443.  Odd thing is this setup worked fine initially, and then suddenly stopped working.

 

This is my 3 security policy that I've created :

 

Rule #1

Source = L3-Untrust

User = Any

Destination Zone = L3-DMZ

Destination Address = public IP

Applicatoin = ssl

Service = application-default

Action = allow

 

Rule #2

Source = L3-Trust

User = Any

Destination Zone = L3-DMZ

Destination Address = public IP

Application = ssl, ms-rdp, web-browsing

Service = application-default

Action = Allow

 

Rule #3

Source = L3-DMZ
Source Address = private IP of the server, also the public IP for the server

User = Any

Destination Zone = L3-Trust

Desination Address = IP of the ADFS server

Application = ssl

Service = application-default

Action = allow

 

Am I missing anything here?  Thank you. 
Note: I am able to RDP to the ADFS WAP server from the internal network. 

 

 

5 REPLIES 5

Cyber Elite
Cyber Elite

Hello,

The policies look ok to me for what you are descvribing. Are you seeing deny's in the logs of the PAN? The only cleanup I would probably make is in policy #3 remove the public IP from it, it does not need to be there from what I can see. Also checkthe traffic and make sure its hitting the proper NAT rule from your Source = L3-Untrust to Destination Zone = L3-DMZ.

 

Regards,

Can you show your NAT policies also?

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Hi.  Here is my two NAT policy for this setup

 

NAT #1

Source Zone = L3-Untrust
Destination Zone = L3-Untrust

Detination Interface = Any
Source Address = Any
Desination Address = public IP
Service = Any

Source Translation = None

Destination Translation = private IP of the ADFS WAP server

 

NAT Rule #2 (u-turn):

Source Zone = L3-Trust
Destination Zone = L3-Untrust

Destination Interface = Any

Source Address = Any

Destination Address = public IP

Service = Any

Source Translation = dynamic-ip-and-port; ethernet 1/1, public IP
Destination Translation = private IP of the ADFS WAP server

 

From the traffic log, I can see the ADFS WAP server is trying to access the internal ADFS server over port 443, but looks like nothing is return from the internal ADFS server.  The session end due to aged out.  I don't see any deny action.  The traffic is allowed as far I can see from the PAN traffic log, but seems the internal ADFS server is not responding for somehow.  I've verified port 443 is opened on the ADFS server's windows firewall on all the profile. 

 

Thanks.

Every session has "Packets sent" and "Packets received" fields in the log.

If packets received is 0 then ADFS WAP server does not reply even to TCP 3 way handshake so most likely Windows firewall.

 

You probably don't have to do source NAT in #2 because source is in L3-Trust and destination is in L3-DMZ.

You need to do DNAT and SNAT usually when souce and destination are in same IP subnet but source talks to destination through public IP.

 

You can test if WAP server replies to TCP SYN if you try to initiate SSH from firewall. Well SSH would not work as it is Windows server but TCP 3 way handshake should work regardless.

 

Example:

 

> ssh source Fw-L3-DMZ-IP port 443 host WAP-IP

> ssh source 192.168.1.1 port 443 host 192.168.1.20

If log shows reply packets then you can change source to fw public ip (currently you snat with nat #2 behind fw public IP) or fw L3-Trust-IP.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Additionally, can you reach the WAP server from another host on L3-Trust?

Are there any other routers between the WAP server and the firewall, or are they on the same L2 network?

Can you perform a packet capture on the WAP server or the switch it is connected to in order to verify the traffic is reaching it?

 

The rules as they are shown look like the traffic should function so I suspect the failure is elsewhere, we just need to figure out where.

  • 3419 Views
  • 5 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!