Destination vs Source Nat

[sgoethals]

I have a pretty good understanding of the difference between SRC and DST Nat, but there is one area that I could use some clarification on.

With SRC NAT, I understand that by selecting BI-Directional, it allows an IP to be translated to an outside address and that Bi-Directional created an implied policy so that someone on the outside could initiate traffic back to the machine from the outside.  It sounds like a good use case would be when the inside machine needs access to the outside and also requires the ability for someone on the outside to connect to it.

Wit DST NAT, I understand that it uses both the untrust (outside) zone for both the source and destination  Zone and that you use a translated address to get it to the proper machine hosted in another zone.  My question is does the use of DST NAT still allow the machine/server to originate traffic outbound?  For example, if you used DST NAT to provide access to a machine in a DMZ,  can that machine initiate traffic to the outside, or does it only allow inbound traffic?

I appreciate any feedback you can provide.

Thanks.

[reaper · Accepted solution]

Hi @sgoethals

All NAT policies are unidirectional in nature (save for reply packets belonging to a session that was inituially started in the appropriate direction)

Hence, the option to either use an inbound and outbound policy, or use the bi-directional option which creates an implied policiy to take the role of the otherwise explicit destination policy you would create

If you do not use the bi-directional option, you will need to create both an inbound and an outbound policy (this is preferred as it provides better visibility of the policies in use) if your server also needs to connect out

A common 'hybrid' is to have several unique inbound policies for different servers/ports and have a 'hide' nat sourcenat outbound for all outbound connections.

This is applied when each individual sertver does not require a unique IP when going out to the internet.

[sgoethals]

Hi @reaper,

Thanks for the reply and the explanation.  This helps.  When you state that creating an inbound and outbound policy provides more visibility, I assume you are referring to the ability to view more detailed information as a result of logs. 

As for security, is there any difference between using either bi-directional or creating separate inbound and outbound policies?

[reaper · Accepted solution]

Hi @sgoethals

no I do mean the actual representation of the policies as they are all visible to you for inspection. Logs will contain all the same information

the bi-directional rules are invisoble so you may 'forget' they exist

they also drop some parameters to allow for dynamically creating a policy that matches outbound traffic

eg. outbound trust to untrust, 192.168.0.1 translated to 198.51.100.1

bi-dir : any to untrust , 198.51.100.1 to 192.168.0.1

admin@PA-220> show running nat-policy

"outbound; index: 1" {
        nat-type ipv4;
        from trust;
        source 192.168.0.1;
        to untrust;
        to-interface ethernet1/3 ;
        destination any;
        service 0:any/any/any;
        translate-to "src: 195.51.100.1 (static-ip) (pool idx: 1)";
        terminal no;
}

"outbound; index: 2" {
        nat-type ipv4;
        from any;
        source any;
        to untrust;
        to-interface ethernet1/3 ;
        destination 195.51.100.1;
        service 0:any/any/any;
        translate-to "dst: 192.168.0.1";
        terminal no;
}

This may be an important factor to consider

[sgoethals]

Hi @reaper,

Thanks again for the clarification.  I appreciate it your explanation and expertise. Makes total sense.