08-03-2011 09:53 AM - edited 03-11-2019 02:07 PM
I've recently set up a LAN-2-LAN VPN tunnel to a 3rd party service provider who uses RFC 1918 private addressing internally and cannot perform NAT on their side of the tunnel. In order to avoid conflicts with our address space I've had to implement DNAT for the address on the 3rd party network that users at my end must access. The tunnel terminates at my end on the outside interface of an ASA-5550 running 8.4.2. While the ASA has 8 interfaces at security levels between 0 and 100, DNAT only need occur for traffic flowing from inside (100) to outside (0).
The following (redacted) addressing applies:
Address of the server on the 3rd party provider network:
192.168.2.155
Mapped address of server as seen on the network at my end:
10.168.2.155
I've currently implemented DNAT using object NAT as follows:
object network remote-server
host 192.168.2.155
nat (outside,inside) static 10.168.2.155
This works as expected, however in examples and discussion I've seen, it appears that the typical way to configure NAT for this scenario is with manual NAT as follows:
object network remote-server
host 192.168.2.155
object network remote-server-mapped
host 10.168.2.155
nat (inside,outside) source static any any destination static remote-server-mapped remote-server
Is there any reason why I should consider using the manual NAT method rather than the object NAT method in this scenario?
Are there any technical reasons why using object NAT in this manner should be avoided?
Solved! Go to Solution.
08-03-2011 10:53 AM
Hi Raphael,
Usually there is no issue with using any nat particularly in ur example, anyuthing would work. But the reason why you would have seen manual nat used more in the examples is because, these manual nats were called nat exempts in pre 8.3 version, and when they are migrated to post 8.3 nats, they end up as manual nats.
In nat exempts you used to define the source and destination for which the traffic should not be natted, in manual nat as well, we do the same thing.
The requirement comes when you need to speciy the source and the destination as well, like:
nat (inside,outside) source static test1 test1 destination static test2 test2
so this becomes useful.
But in ur case:
object network remote-server
host 192.168.2.155
nat (outside,inside) static 10.168.2.15
nat (inside,outside) source static any any destination static remote-server-mapped remote-server
the destination doesn't matter, it is any any, so both would work.
Let me know if you ahve any questions.
Thanks,
Varun
08-03-2011 10:53 AM
Hi Raphael,
Usually there is no issue with using any nat particularly in ur example, anyuthing would work. But the reason why you would have seen manual nat used more in the examples is because, these manual nats were called nat exempts in pre 8.3 version, and when they are migrated to post 8.3 nats, they end up as manual nats.
In nat exempts you used to define the source and destination for which the traffic should not be natted, in manual nat as well, we do the same thing.
The requirement comes when you need to speciy the source and the destination as well, like:
nat (inside,outside) source static test1 test1 destination static test2 test2
so this becomes useful.
But in ur case:
object network remote-server
host 192.168.2.155
nat (outside,inside) static 10.168.2.15
nat (inside,outside) source static any any destination static remote-server-mapped remote-server
the destination doesn't matter, it is any any, so both would work.
Let me know if you ahve any questions.
Thanks,
Varun
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide