NAT Rules

[MikeBull]

Hello,

I was wondering if anyone could explain the following scenario to me as I seem to have found a bug with NAT policies.

On our PA-2050 v5.0.8 I have configure three zones: inside, dmz and outside, and a host in the DMZ. I created two NAT policies, one is static for the spam appliance (MX) and another is a catch-all for other servers in the DMZ, they are defined IN THE FOLLOWING ORDER as follows:

Name: MX OUT

Source Zone:          inside

Destination Zone:    outside

Source Address:     10.3.4.5 (its gateway is on the dmz zoned interface)

Source Translation:  static-ip

                              External IP 1

                              Bi-directional

Name: DMZ NAT

Source Zone:          dmz

Destination Zone:    outside

Source Translation:  dynamic-ip-port

                              External IP 2

These NAT Rules also have accompanying policies. The policy associated to 'MX OUT' has a destination IP of 'External IP 1' and a 'Destination Zone' of 'dmz'

I was looking through the config today and I noticed that my first NAT policy 'MX OUT' had an incorrect 'Source Zone' which you can see defined above as 'inside' (should be 'dmz' not 'inside').

As everything was working as expected,I proceeded to check the logs to see HOW it was working. As I expected - since the 'MX OUT' rule was incorrect - traffic destined for the outside from 10.3.4.5 ( MX ) was translated out 'External IP 2' found on the second catch-all NAT Policy 'DMZ NAT'.

Incoming mail traffic was showing in the logs with a 'Destination Address' of 'External IP 1' with a 'Destination Zone' of 'dmz' and 'NAT Destination IP' of '10.3.4.5' ( MX ).  Scratching my head, I proceeded to check the MX record for our domain and it was indeed pointed to 'External IP 1' which is attached to the first bi-directional NAT rule 'MX OUT' which has the incorrect 'Source Zone' of 'inside'.

Could someone explain to me why traffic destined for 'External IP 1' from the internet somehow made it to '10.3.4.5' ?

My assumption is that the PA-2050 does not evaluate the 'Source Zone' for C2S flow and only matches on 'Source Translation' IP, 'Destination Zone' and 'Source Address' IF bi-directional.

My issue with this is that the policy was defined with an incorrect 'Source Zone' and failed to work from 'dmz' to 'outside' but still functioned from 'outside' to 'dmz'. This seems like a bug?

I hope I laid that out in a way that it makes sense.

Thanks

Mike

[hshah · Accepted solution]

hi Mike,

If you execute command "show running nat-policy", you will see something like bellow.

admin@84-PA-VM-300> show running nat-policy

Static_NAT {

        from dmz-L3;

        source 1.1.1.1;

        to untrust-L3;

        to-interface  ;

        destination any;

        service  any/any/any;

        translate-to "src: 100.1.1.1 (static-ip) (pool idx: 3)";

        terminal no;

}

Static_NAT {

        from any;

        source any;

        to untrust-L3;

        to-interface  ;

        destination 100.1.1.1;

        service  any/any/any;

        translate-to "dst: 1.1.1.1";

        terminal no;

}

ABove output is for just one rule, See the second part. It says "source any". So, by design even if you configure wrong rule NAT will work.

Regards,

Hardik Shah

[MikeBull]

I typed the command and I see exactly what you are saying. But for what reason would this work 'by design'? I guess that is a question for a PA Engineer?

[hshah]

Hi Mike,

They will tell you exactly same thing. I had exact same issue in past. Thats the reason I found root cause in 2 minutes

Regards,

Hardik Shah

[MikeBull]

I assumed they were evaluating the rules like that (was the only thing that made sense) but I didn't pull it up on the command line to look at the raw configuration. I guess my real question is WHY? Why is a NAT Policy created - visible only in the CLI - that doesn't match the one defined in the interface, it just doesn't make sense. I guess I will have to call support for clarification.