topic Re: strange behavior of bidirectional NAT in General Topics

strange behavior of bidirectional NAT

Andreikin — Thu, 21 Apr 2022 19:26:28 GMT

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!

Re: strange behavior of bidirectional NAT

TomYoung — Fri, 22 Apr 2022 00:30:33 GMT

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

Re: strange behavior of bidirectional NAT

Andreikin — Fri, 22 Apr 2022 06:47:01 GMT

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.

Re: strange behavior of bidirectional NAT

TomYoung — Fri, 22 Apr 2022 16:24:05 GMT

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.

Re: strange behavior of bidirectional NAT

Andreikin — Mon, 25 Apr 2022 08:34:45 GMT

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.

Re: strange behavior of bidirectional NAT

S_Alad — Mon, 25 Apr 2022 14:29:15 GMT

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

Re: strange behavior of bidirectional NAT

OtakarKlier — Mon, 25 Apr 2022 14:42:31 GMT

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,