I recently got a question from a collegue regarding address translations in Cisco ASA. He wrote:
Got a question from a customer if you can do the following:
1. NAT the . IP address of a machine located on the DMZ to inside with the same address as the NAT has been: at the outside (ie publish public address inwards too)
2. Source NAT for inside addresses (clients) when they must go above the DMZ server (in the “public” address) so that the source is a different puclic address.
Have not tested yet so I do not know but the config must be abit weird. 🙂
ok. Lets try. I put together a quick lab-setup. A 3-legged ASA with a one-legged router on each firewall-interface:
interface Vlan10
nameif outside
security-level 0
ip address 200.1.1.1 255.255.255.0
!
interface Vlan20
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
!
interface Vlan30
no forward interface Vlan20
nameif dmz
security-level 50
ip address 10.2.2.1 255.255.255.0
!
And the routers.
R1:
interface FastEthernet0
ip address 200.1.1.99 255.255.255.0
duplex auto
speed auto
end
R2:
interface FastEthernet0
ip address 10.1.1.99 255.255.255.0
duplex auto
speed auto
end
and R3:
interface FastEthernet0
ip address 10.2.2.2 255.255.255.0
duplex auto
speed auto
end
Ok. R1 is the outside host on internet. R2 is an inside host on our corporate network. R3 is this magical server on DMZ. In this example it is a high performance telnet server!
line vty 0 4
no login
First, make sure that this is reachable from internet. We do a static and allow the traffic on outside acl:
static (dmz,outside) 200.1.1.2 10.2.2.2 netmask 255.255.255.255
access-list OUTSIDE extended permit tcp any host 200.1.1.2 eq telnet
Verification. Telnet from R1 to public IP:
R1#telnet 200.1.1.2
Trying 200.1.1.2 ... Open
R3>
Great. Now we want to reach the DMZ server from inside. Since this is higher security level to lower and we dont have any acl on inside we dont have to care about open the traffic. But we want to use an OUTSIDE address as destination ip to reach a DMZ host. Lets try a static:
FW(config)# static (dmz,inside) 200.1.1.2 10.2.2.2
The command above seems weird, right? I agree. Someday when I have a lot of time I will explain the theory but for now, just trust me!
Verification:
R2#telnet 200.1.1.2
Trying 200.1.1.2 ... Open
R3>
Next step is to hide the source address of that telnet client on inside. Right now it is using its own source ip:
R3>en
Password:
R3#
R3#sh users
Line User Host(s) Idle Location
0 con 0 idle 00:08:09
* 6 vty 0 idle 00:00:00 10.1.1.99
Interface User Mode Idle Peer Address
R3#
So, how do we accomplish that? The easiest way is to use a policy nat-statement. We create an access-list which defines which traffic to translate. We then create a nat-statement with a nat-id of your choice and call the access-list. Finaly we define which global ip to use. (outside. Remember dmz is outside relative to inside since dmz has lower security-level)
access-list Inside2DMZ extended permit tcp 10.1.1.0 255.255.255.0 host 200.1.1.2 eq telnet
nat (inside) 1 access-list Inside2DMZ
global (dmz) 1 200.1.1.10
Verification:
R2#telnet 200.1.1.2
Trying 200.1.1.2 ... Open
R3>sh users
Line User Host(s) Idle Location
* 6 vty 0 idle 00:00:00 200.1.1.10
Interface User Mode Idle Peer Address
R3>
Voila! So, the client is on a private ip network 10.1.1.0 and establish a connection to what he think is on outside, because it is an public/outside ip. The traffic passes the magic ASA and the server on DMZ believes that the client is on internet since it has a public/outside source ip.
Mission accomplished.
