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?

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

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

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

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

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!