strange behavior of bidirectional NAT

[Andreikin]

hello All,

Today I've spotted weird behavior:

We have 2 static bidirectional NAT translations between UNTRUST and DMZ interfaces for public IPs. Also we are allowing certain applications in for those public NATed IPs from any IP addresses using only applications and not service/ports. From logs we see that traffic which is properly allowed and working has UNTRUST as source zone and DMZ as destination zone. This works fine. But for some of connections we see that source and destination zones are UNTRUST and traffic is been dropped as we have specific rule to drop such traffic within same zone. Both destination IPs/ports are the same every time. I would assume actual forward decision is done incorrectly, hence part of the traffic been denied. Also denied traffic in logs is matched as 'not-applicable' in application column - which is understandable, but working not how it should.
 

I assume PaloAlto should perform kind of forwarding decision to find out what zone destination interface belongs to. It might be regular ARP lookup or routing lookup. Since DMZ interface/subnet are directly connected to a firewall, there's no routing to DMZ hosts, this means it either regular NAT is broken or ARP cache, but as part of the traffic is going through normally I doubt that. 

Any thoughts or hints here please?

Thanks!

[TomYoung]

Hi @Andreikin ,

With the information provided, it sounds like the traffic is not matching the NAT rule.  Could you add the "NAT Applied" column under Monitor > Logs > Traffic and let me know what is says for the allowed and denied sessions?

Thanks,

Tom

[Andreikin]

Hello TomYoung,

Thanks for your reply. The NAT applied shows NO for sessions within same zone and YES for sessions between DMZ and Untrust. That's the whole point actually - SOME connections for the same public IP (NATed bidirectionally to private) have their NAT applied and marked as allowed, some of them - don't and marked dropped. Within same NAT translation, which is bidirectional and does not involve any source changes or ports. Just regular 1:1 mapping between Public and Private IPs. So it is hard for me to understand why there's a difference in zone selection while NAT translation is the same. 

[TomYoung]

Hi @Andreikin ,

Thank you for the information.  You have confirmed that the traffic with "NO" NAT Applied is not matching the NAT rule (or any NAT rule).  The difference is not zone selection, but NAT rule selection.  The destination zone forwarding decision is based upon the NAT rule, if it matches.  I hear you that the NAT rule is very basic with just real and mapped IP address only.  There is nothing else which would cause the traffic not to match it?

Thanks,

Tom

Edit:  If the answer is not apparent in the GUI, use the CLI command "show session id" followed by the session number of a working and non-working session and compare every line.

[Andreikin]

Hi,

There's no ports or anything like this affecting NAT translation. We just simply NAT private IP to public IP for a same host. 

As mentioned we still not clear why some of the traffic been matched NAT translation (and shows proper zones in logs) and some of them don't. Will have a session with support to day to go through the case. 

[S_Alad]

show some screenshots of your NAT, Security rule  and log, that would help in proffering solution (gray out sensitive details)

[OtakarKlier]

Hello,

Also check the logs to see which nat policy is being applied to the traffic. It could be the NAT policy to too low on the list. Just like security policies, the NAT checks top down, left to right. Once it matches, it uses it.

Regards,