Inbound traffic to DMZ issue

[x]

We have reports of certain users not being able to access our public website but majority of users are able to. The traffic log shows that the application is incomplete. Packet capture reveals the 3-way handshake does not complete and the session times out. The same person who is NOT able to access the public website is able to access another website of ours that is hosted on another IP address but on the same firewall. The difference between the two sites are as follows:

Different external IPs but same subnet

Different internal Zones (1 server is on DMZ; not working and 1 server is on the Trust zone; working)

Different gateways, different switches

The DMZ's gateway is the firewall while the server on the trust side's gateway is a core switch

Has anyone seen something like this before? Again, it works for 99% of the users but there are a number of users that are not able to get to the website for some reason. We initially thought it could be a routing issue with the ISP that we use since majority of the users who reported the issue belongs to the same ISP that we use. HOWEVER, we did find a user who uses the same ISP and IS ABLE to browse.

NAT is a regular destination NAT

Untrust to Untrust

Src IP: Any

Dst IP: Public IP of server

Destination translation IP: DMZ IP of the server

Policy is a regular allow inbound policy

allow access to website

Zone: Untrust to DMZ

Src IP: Any

Dst IP: External IP of DMZ server

Some other info that might help.

There are two ISPs but only one is used and the other is a backup in case the other one is down. I'm using PBF to achieve this as per the PBF doc/KB.

There is a zone protection profile and enabled all of them. I removed it temporarily but it didn't help.

I tried to do a static bi-directional NAT as a test but it didn't seem to help

Any help would be appreciated!

[hshah]

Hi X,

Please provide us snap shot for traffic log. If only one packet is sent and 0 packets are recieved than most likely web-server is not responding. There are other possibilities as well.

But, please provide us snap shot for traffic log first, based on that detail we can provide some information.

Regards,

Hardik Shah

[HULK]

Hello x,

It would be difficult to isolate the issue from above mentioned description. There could be many reasons, while traffic was not through the PAN firewall.

I would suggest a few things to check if there would be another occurrence of the same issue.

In the GUI --> Traffic log, you may use filters like ( addr.src in IP_ADD_OF_THE_TESTING_PC [public IP]) and ( addr.dst in IP_ADD_OF_THE_DESTINATION ) to check the security policy that the traffic hitting. Also you can check the real time session in the CLI by using 'show session all filter source IP_ADD_OF_THE_TESTING_PC destination IP_ADD_OF_THE_DESTINATION'.

>  If there is an session exist for the same traffic,  then please apply  CLI command PAN> show session id XYZ   >>>>>>>> to get detailed information about that session, i.e NAT rule, security rule, ingress/egress interface etc.

>  verify the global counters, if a specific "DRP" counter is increasing rapidly. The command show counter global provides information about the processes/actions taken on the packets going through the device; if they are dropped, nat-ed, decrypted etc.  These counters are for all the traffic going through the device and are useful in troubleshooting issues; like poor performance, packet loss, latency etc. It is advised to use the command show counter global filter packet-filter yes delta yes in conjunction with filters to obtain meaningful data.

For more information, you can follow the DOC What is the Significance of Global Counters?

> You can enable FLOW BASIC feature to understand the exact reason behind the failure:

> debug dataplane packet-diag clear all

> debug dataplane packet-diag set filter match source  IP_ADD_OF_THE_TESTING_PC destination IP_ADD_OF_THE_DESTINATION

> debug dataplane packet-diag set filter match source IP_ADD_OF_THE_DESTINATION destination  IP_ADD_OF_THE_TESTING_PC

> debug dataplane packet-diag set log feature flow basic

> debug dataplane packet-diag set log feature tcp all

> debug dataplane packet-diag set filter on

> debug dataplane packet-diag set log on

~~~~~~~~~~~~~~~~ Initiate traffic through the PAN firewall/try to browse a website ~~~~~~~~~~~~~~~~~~~~~~~~~

> debug dataplane packet-diag set log off

> debug dataplane packet-diag aggregate-logs

> less mp-log pan_packetdiag_log.log

For more information, you can follow the DOC: Packet Capture, Debug Flow-basic and Counter Commands

Hope this helps.

Thanks

[Keson]

I am configuring inbound traffic on a PA-500, to allow traffic from the internet to reach a web server in the DMZ.

I've followed the examples found in this forum and the internet traffic still does not reach a web server in the DMZ.  The U-turn doesn't work either for internal users.   Internal users can get to the web sever via internal route. The only thing I still don't know is if I need a static route in the Virtual Router to route inbound traffic.  Does anyone have any idea?  Please help.  Thanks.

[Keson]

I found the solution by myself and post the result here so others may benefit from it.

The external IP of the server "hidden" in the DMZ must be in the same subnet as the untrust interface.  This is how the external IP of the server can be found, translated (NAT'ed) and allowed on through the firewall.

Hope you find it helpful.

Keson

[Claudech]

Did you ever find a solution to this problem?