NAT exemption with statics

[jim.r.waller]

I am trying to get this to work. Although I see Cisco doesn't recommend deny statement in the ACL for NAT exemptions.

nat (inside) 0 access-list no-nat

access-list no-nat line 1 deny ip host 172.25.0.180 any

access-list no-nat line 2 deny ip host 172.25.0.181 any

access-list no-nat line 3 deny ip 10.10.0.0 255.255.0.0 any

access-list no-nat line 3 deny ip 172.25.0.0 255.255.0.0 any

static (inside,outside) 172.25.0.180 10.10.22.20 netmask 255.255.255.255

static (inside,outside) 172.25.0.181 10.10.242.42 netmask 255.255.255.255

Is there any other way translate 172.25.0.180 to 10.10.22.20 from outside to inside with NAT exemption enabled?

[fedrodri]

Hi,

I'm not really sure what is that you are trying to accomplish, but access-list no-nat, as you said, should not take "deny" statements (and remember that anything that you put on that ACL has source on the high security interface, destination on the lower). Anyway, if you want to "translate 172.25.0.180 to 10.10.22.20 from outside to inside", then you can use the following static statement:

static (outside,inside) 10.10.22.20 172.25.0.180

Of course that you would need to remove the other static that you put in there:

no static (inside,outside) 172.25.0.180 10.10.22.20

clear xlate global 172.25.0.180

clear xlate local 10.10.22.20 (just in case)

And again, ACL for NAT excemption can have only "permit", and the moment it detects a "deny" it would stop checking the NAT excemption rule.

Hope that helps!

Federico Rodriguez

[jim.r.waller]

Thanks for the help. The first thing we were trying to accomplish was to not nat anything through this firewall. Then a new requirement arose and now we need to translate the two IP addresses 172.25.0.180 and 172.25.0.181 to 10.10.22.20 and 10.10.242.42 on the inside.

[fedrodri]

OK, so in that case you can use the statics as suggested (and get rid of the ones that you have there; with those static NATs you are translating

10.10.22.20, on the inside, to 172.25.0.180 on the outside, and I understand that you want it the other way around). So, what you would need is something like this:

1. No-NAT for traffic going out, right? In this case remember that NAT-0 + ACL (NAT excemption) is bidirectional and would allow inbound traffic (if allowed by an ACL on the lower security interface) from any IP/network specified as the destination on the NAT-0 ACL, and the destination of that inbound traffic is specified as the source on the NAT-0 ACL. So as an example:

static (outside,inside) 172.25.0.180 10.10.22.20

access-list no-nat permit ip any host 172.25.0.180

nat (inside) 0 access-list no-nat

access-list inbound permit ip host 10.10.22.20 any

access-group inbound in interface outside

So, in this example we are first translating 10.10.22.20, which is on the outside of the PIX, to 172.25.0.180, that's how it is going to be translated as it traverses the PIX (that's the IP that the inside network will see). This outside static NAT is not bidirectional, we still need to have a directional translation rule to allow inbound traffic. This is when we setup the exemption NAT. The ACL to be applied there, as said on previous post, needs to have the source on the inside, and destination on the outside. In this case, we selected the desination to be the translated IP of the outside host. So, whenever any host on the inside network would try to go to that outside host (call would be made to the translated IP, and not the original one), then it will get passed the PIX untranslated... Note that this is going to be the case only for traffic matching the NAT-0 ACL.

Now, if you would like to bypass NAT for the rest of the traffic, I guess that you can "play around" with the ACL applied to the NAT-0 ACL statement and with the ACL applied to the outside interface to allow only the desired traffic. Another thing that you can do is to use Identity NAT (NAT-0, without ACL). The only drawback I see regarding Identity NAT is that "you can accept the inbound traffic only when the traffic is initiated from the inside and after the xlate is created" (from the command reference, NAT command -usage guidelines):

http://cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/mr.htm#wp1032129

This means that you need to pay special attention to what you allow with the outside ACL... :0)

I hope that it helps, and didn't confuse you. If you have any questions, let me know.

Thanks and regards,

Federico Rodriguez

[davemit]

Federico, I have a question regarding the directional nature of NAT. Is the following correct:

NAT is uni-directional, and NO-NAT is bi-directional?

For example, if an address is translated using NAT, only stateful return traffic is allowed. External traffic cannot originate. This it is UNI-directional.

However, if you implelemt a NAT 0, does it become BI-directional? Meaning that you have basically set up a static translation?

If I am understanding this correctly, what is the function difference between a NAT 0 (wiht ACL) and a static translation?

Thanks in advance for the clarification.

- Dave

[fedrodri]

Dave,

Thanks! You are correct. Regular dynamic NAT is UNI-DIRECTIONAL (nat/global statements). But, if you configure NAT 0 (without ACL), then it becomes "BI-DIRECTIONAL" in the way that it will allow inbound connections (I'm not talking about stateful returned traffic here) only if there is an original connection initiated from the high security interface to the host on the low security interface and the xlate is created. In that case outside host can initiate connections to the high security host, if allowed by the ACL applied to the low security interface. :0)

Now, the main difference between NAT 0 + ACL and a static NAT is that the NAT 0 ACL is BI-DIRECTIONAL only for traffic matching the criteria of the ACL applied to it, whereas the static is just general (you add a little more flavor to this and make it a bit more "complicated" by adding static policy NAT to the equation: static (high,low) global-ip ACL ).

Then, the other difference between NAT 0 + ACL and static NAT would be that the static NAT does create an xlate on the PIX memory, NAT 0 + ACL does not!!!

I hope that's the answer that you were looking for... Let me know if you have any further questions.

Thanks,

Federico Rodriguez

[davemit]

Thank you for the explanation.

So, with NAT 0 + ACL, if an inside host does not first make a connection, then outside originating traffic will not work, correct? Again, we're not talking stateful return traffic here. If I boot my PIX up, and I am only using NAT 0 + ACL for the transaltions, and the first attempted conenction is from outside, will it work?

Also, in regards to your comment about memory usage, is it GOOD to have the xlate in memory? Or is that a bad thing because it uses up more memory?

Basically, what is the recommended way to translate traffic between inside and outside, or is there a preference?

Thanks,

Dave

[jim.r.waller]

I can answer the first question. NAT 0 with an ACL is bi-directional. Meaning the connections can be initiated for the inside or the outside.

[getmedrew]

Dave the first question is already answered so let me help with the second one.

The xlate table will always show in the memory, there is no way to separate one or the other, when you do show xlate those current translations are using part of the pix firewall memory, in regards of the question if there is a preference to translate the traffic one or another way, there is no preference at all; I mean, it all depends on the necessity of the moment. My friend Federico can corroborate this story for you, but it is not necessary.

To sum it up:

- Federico provided information on how to do the translations outside to inside

- Nat 0 + ACL will match the criteria based on the ACE's

- Translation methods are as per need basis.

Hopefully this has clarified your doubts.

[fedrodri]

You sum'd it up so perfectly!!! Thanks!

Federico Rodriguez

[jogillis]

One more question/comment about this. Don't you have to make sure that the packets with destination 10.10.22.x and 10.10.242.x networks will be routed back to the pix?

[fedrodri]

We've been assuming throughout all this conversation that routing is working properly... but yes, you do need to make sure that 10.10.22.x and 10.10.242.x are routed correctly by the PIX.

Best regards,

Federico Rodriguez