KB ID 0001582
I got asked today if this could be done. My first response was ‘why?’ I cant really think of a use case for this. But a client had this on their previous firewall and were migrating to a virtual ASA, and wanted the config replicating.
So I built something like this;
To be fair, my first thought was ‘why not simply add an additional internal IP to the web server, and NAT the second public IP to that?’. That was my reserve answer, if it dind’t work!
Turns out it was pretty easy, I had the following working quite quickly;
! object network OBJ-Web-Host-Public range 198.51.100.2 198.51.100.3 ! object network OBJ-Web-Host-Private host 192.168.100.10 nat (inside,outside) static OBJ-Web-Host-Public ! access-list inbound line 1 extended permit tcp any object OBJ-Web-Host-Private eq www !
Note: Change the ACL name inbound to match your incoming access-list.
Feeling pleased with myself I went over, to help get it deployed. But there was a problem, the public IP addresses in the clients case were not sequential (contiguous). So I thought I’d simply create an object group and put two hosts in it and use that instead, but that did not work 🙁
I didn’t think creating two NAT statements would work, as the second one would complain it overlaps with the first one, surely? Well no it didn’t, and it worked fine.
! object network OBJ-Web-Host-1 Host 192.168.110.14 nat (inside,outside) static 198.51.100.11 ! object network OBJ-Web-Host-2 Host 192.168.110.14 nat (inside,outside) static 198.51.100.33 ! access-list inbound line 1 extended permit tcp any object OBJ-Web-Host-1 eq www access-list inbound line 2 extended permit tcp any object OBJ-Web-Host-2 eq www !
Everyday’s a school day! Sometimes the simplest answer is staring you in the face.
Related Articles, References, Credits, or External Links