policy nat vs static nat

Unanswered Question
May 9th, 2007
User Badges:
  • Bronze, 100 points or more

hello experts


i am in the middle of a serious problem and have to decide on one that is to use policy nat or static nat.


all i want to know is which one is a better option to use if considering that fact that there will be really high volume of traffic and it will be pix 515E, having said that it would mean pix would be doing high load of nat, also nat will be for both side e.g. outside and inside source ip addresses with contrast using statics.


coming back to my point that which option to use. any consideration / pros and cons for both policy nat and static nat.


your advice and help would be really apperciated and i really need your quick reply as i am having doubts using policy nat in high volume of traffic as once using policy nat i faced a serious problem in similar situation like today but i still need experts opinion on it.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Jon Marshall Wed, 05/09/2007 - 22:48
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Could you give some more details on what traffic flows you are trying to achieve.


Policy NAT and static NAT do not achieve the same thing. You would use policy NAT when you want to apply different NAT policies depending on where the traffic is coming from, going to, or both.

You would use static NAT's when the traffic is going the same way all the time.


Jon

zulqurnain Wed, 05/09/2007 - 23:22
User Badges:
  • Bronze, 100 points or more

hello jon,


thanks for the reply, the thing is that the traffic will be ipsec and it will be high volume while not just nat source ip addresses and destination ip addresses but also port level assignment as well as outside and inside nat will be configured.


hope this is what you are looking for?

Jon Marshall Wed, 05/09/2007 - 23:54
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


You can do both inside and outside NAT without using policy NAT for destination and source IP addresses.


Sorry to keep asking questins but could you elaborate on what you mean by port level assignment.


Jon

zulqurnain Thu, 05/10/2007 - 01:25
User Badges:
  • Bronze, 100 points or more

Yes you are 100% correct it can be done using static instead of policy nat


just to explain you what problem i face


when host A connects on the published ip address 60.10.135.72 and connects to 20.172.216.4 it works as per the static entires


Quote:

static (inside,outside) tcp 60.10.135.72 3392 20.172.216.4 3392 netmask 255.255.255.255

static (inside,outside) tcp 60.10.135.72 3394 20.172.216.4 3394 netmask 255.255.255.255



when host A (same host) connects on the publish ip address 60.10.136.72 and connects to 16.172.23.1. we have to change the source ip address which is 16.172.5.7 to 20.172.220.4 because 16.172.23.1 will not accept connection from other than 20.172.220.4, now as per static entries it also works




Quote:

static (outside,inside) 20.172.220.4 16.172.5.7 netmask 255.255.255.255

static (inside,outside) 60.10.136.72 16.172.23.1 netmask 255.255.255.255



problem 1: on the netstat of host B it looks like that the traffic is coming from 20.172.220.4 instead of 16.172.5.7, where as it should be 16.172.5.7 only


i dont want host B to see traffic coming from natted ip 20.172.220.4, instead it should be from 16.172.5.7 whereas for host C it should look like 20.172.220.4.


Hope it helps, so any suggestions? please do tell

Jon Marshall Thu, 05/10/2007 - 02:10
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


I'm making a couple of assumptions here, so correct me if i'm wrong.


Host C is 16.172.23.1

Host B is just another destination host.


In essence to do what you want you do need policy NAT.


I'm assuming that the connection is being made on port 3394 but you could change it.


access-list hide_source permit tcp host 16.172.5.7 host 60.10.136.72 eq 3394


nat (outside) 3 access-list hide_source outside


global (3) 20.172.220.4


This would need testing. I have used policy NAT outbound using ip in the access-list rather than specific tcp ports and it worked fine for me but i haven't used the exact type config above.


Hope i've understood


Jon

zulqurnain Thu, 05/10/2007 - 04:18
User Badges:
  • Bronze, 100 points or more

hello jon,


YES, you r correct in your assumption.


in this contrast yes, i would need policy nat and i tried configuring it in the other way i.e.


access-list hide_source permit ip host 16.172.5.7 host 60.10.136.72

static (outside,inside) 20.172.220.4 access-list hide_source


it worked successfully but now my concern is will it be a good strategy to have or should i still go for static nat meaning should i ask the other party to access us from two different source addresses even if they have to do nat or there end.


on the other hand when i tried implementing the one you have mentioned, the moment i configure it all other nats starts giving error message in the syslog i.e.


"no translation group found for blah blah"


weird i know. anyways, so what do you believe now should be policy nat or static nat? also there will be other nats on the same FW but all inside from


Jon Marshall Thu, 05/10/2007 - 04:59
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Apologies then for the duff configuration. If i get a chance i'll put it on our lab and see why it doesn't work.


Anyway, you could ask them to use 2 different source IP addresses and just use static NAT at your end. It all depends on how confidence you have in their ability to set it up correctly. I have dealt with many 3rd parties for remote access and they vary wildly in their technical know how.


If you plan to expan this solution then you may find that some 3rd parties can do the type of NAT you need and some can't. You then end up with a mess on your firewall with you doing policy nat for those that can't do NAT and static NAT for those that can.


It comes down to your judgement as to how scalable your solution is and how much more complexity you are prepared to have on your device.


HTH


Jon

"thanks for the reply, the thing is that the traffic will be ipsec and it will be high volume while not just nat source ip addresses and destination ip addresses but also port level assignment as well as outside and inside nat will be configured."


Actually, you will configure NAT Exemption.

Define an ACL to prevent your IPSEC traffic from NATing.


Example:

nat (inside) 0 access-l NO_NAT


access-l NO_NAT permit ip 192.168.1.0 255.255.255.0 192.168.4.0 255.255.255.0


Then define your Interesting Traffic in a separate ACL. When an IP packet arrives at the inside interface of the firewall, Network Address Translation (NAT) is checked. After that, ACLs for the crypto maps are checked.

The nat 0 (NAT Exemption) ACL defines what should not be included in NAT. The ACL in the nat 0 command defines the source and destination address for which the NAT rules on the firewall are disabled. Therefore, an IP packet that has a source and destination address that matches the ACL defined in the nat 0 command bypasses all the NAT rules on the firewall. In order to implement LAN-to-LAN tunnels between a firewall and another VPN device with the help of the private addresses, use the nat 0 command to bypass NAT. The rules on the firewall prevent the private addresses from being included in NAT while these rules go to the remote LAN over the IPsec tunnel.


After the NAT inspections, the firewall checks the source and destination of each IP packet that arrives at its inside interface to match the ACLs defined in the static and dynamic crypto maps. If the firewall finds a match with the ACL, the firewall takes any of these steps:


If there is no current IPsec Security Association (SA) already built with the peer IPsec device for the traffic, the PIX initiates the IPsec negotiations. Once the SAs are built, it encrypts the packet and sends it over the IPsec tunnel to the IPsec peer.


If there is already an IPsec SA built with the peer, the firewall encrypts the IP packet and sends the encrypted packet to the peer IPsec device.


access-l 119 permit ip 192.168.1.0 255.255.255.0 192.168.4.0 255.255.255.0


You will then define this ACL within your crypto map.


Please rate if you are satisfied.


Cheers!

Actions

This Discussion