Destination vs Source Nat

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Destination vs Source Nat

L2 Linker

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.

2 accepted solutions

Accepted Solutions

Cyber Elite
Cyber Elite

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.

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

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

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

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.

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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?

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

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Hi @reaper,

 

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

 

  • 2 accepted solutions
  • 2389 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!