Solved: ASA: Xlating addresses prior to L2L IPSEC tunnel

mmertens · ‎05-11-2010

I have an L2L VPN tunnel that I'd like to move on to an ASA from a 3000 centrator. The IPSEC tunnel will terminate on a new sub-interface and I'll need to NAT the traffic from two interfaces prior to it entering the tunnel. The inside traffic will originate from two ASA interfaces: Inside and DMZ. Inside already has a NAT 1 statement for nating to the outside; DMZ does not.

Let's say the Inside subnet is 10.1.1.0/24

Let's say the DMZ interface is 10.10.10.0/24

and I'm giong to translate IPSEC-bound traffic to 192.168.1.0/24 (multiple host-to-host translations). The remote network is 88.1.1.0/24

So I have a proposed config:

global (outside) 1 5.5.5.5

nat (inside) 1 10.1.1.0 255.255.255.0

! For my traffic to be NATed that's heading to the IPSEC tunnel from the inside:

access-list IPSEC_1 extended permit ip host 10.1.1.1 88.1.1.0 255.255.255.0

static (inside,IPSEC) 192.168.1.1 access-list IPSEC_1

! For my traffic to be NATed that's heading to the IPSEC tunnnel from the DMZ:

access-list IPSEC_2 extended permit ip host 10.10.10.1 88.1.1.0 255.255.255.0

static (dmz,IPSEC) 192.168.1.2 access-list IPSEC_2

MY question(s):

1) DMZ did not have a NAT statement before, do I know need one to NAT for traffic destined to the tunnel? Would I have to do a policy NAT command so the traffic coming in from the outside interface, destined to the DMZ, uses those (dmz,outside) static commands and NOT the new IPSEC NAT commands?

2) Can I just combine my access-list and static commands into JUST static cmmands ("classic static")

static (inside,IPSEC) 192..168.1.1 10.1.1.1 netmask 255.255.255.255

3) If I do option "2", do I still need the access-list command for traffic destined to remote end of the tunnel?

I appreciate any and all help!!!!!!

Thanks,

Mike.

Federico Coto Fajardo · ‎05-11-2010

Mike,

As you mentioned..

Let's say the DMZ interface is 10.10.10.0/24

To NAT the host 10.10.10.1 to 192.168.1.2 when going through the tunnel to 88.1.1.0/24, you require the Policy NAT below:

access-list DMZ_VPN extended permit ip host 10.10.10.1 88.1.1.0 255.255.255.0
static (dmz,outside) 192.168.1.2 access-list DMZ_VPN

The above statement will not interfere if you have regular NAT configuration for your DMZ already.
i.e
nat (dmz) 1 10.10.10.0 255.255.255.0
global (outside) 1 interface

The interesting traffic will be like this:

access-list DMZ_IPsec permit ip host 192.168.1.2 88.1.1.0 255.255.255.0

In summary,
You're translating the DMZ host 10.10.10.1 to 192.168.1.2 when going through the tunnel only. This will not affect communication
to the Internet or from other interfaces.

Federico.

View solution in original post

Federico Coto Fajardo · ‎05-11-2010

Mike,

1. Do you need to NAT the DMZ traffic through the tunnel?
If so, you will need Policy NAT. If not, you will need NAT 0 with ACL to bypass NAT.
When nat-control is enabled on the ASA, you require a NAT statement for all traffic passing through the ASA.

2. If you just use regular static commands, then you cannot manipulate when is the translation going to take place.
(as in Policy NAT), in regular statics the translation will always take place.

You need to know that the NAT check on the ASA follow this order:

1. NAT 0 with ACL
2. Static NAT/PAT
3. Policy NAT
4. Dynamic NAT/PAT

If you have any questions please let us know.

Also, this might help:

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_overview.html

Federico.

mmertens · ‎05-11-2010

Frederico,

1) Yes, I need to NAT the traffic from the DMZ that will enter the IPSEC tunnel (interface IPSEC), but do not want to affect the static translations for outside-> dmz traffic. Therefore, it sounds like I'll need a NAT (policy) command on the DMZ interface for my traffic destined to the tunnel. Does this mean I need to convert my current host static commands for outside-> DMZ so that they are policy static/NAT commands? So I'll have two policy NATs, one for outside-> dmz traffic and one for dmz-> IPSEC traffic?

2) I think this is coverred by my questions above.

Thanks!

Mike.

Federico Coto Fajardo · ‎05-11-2010

Mike,

As you mentioned..

Let's say the DMZ interface is 10.10.10.0/24

To NAT the host 10.10.10.1 to 192.168.1.2 when going through the tunnel to 88.1.1.0/24, you require the Policy NAT below:

access-list DMZ_VPN extended permit ip host 10.10.10.1 88.1.1.0 255.255.255.0
static (dmz,outside) 192.168.1.2 access-list DMZ_VPN

The above statement will not interfere if you have regular NAT configuration for your DMZ already.
i.e
nat (dmz) 1 10.10.10.0 255.255.255.0
global (outside) 1 interface

The interesting traffic will be like this:

access-list DMZ_IPsec permit ip host 192.168.1.2 88.1.1.0 255.255.255.0

In summary,
You're translating the DMZ host 10.10.10.1 to 192.168.1.2 when going through the tunnel only. This will not affect communication
to the Internet or from other interfaces.

Federico.

mmertens · ‎05-12-2010

Okay, I guess my last question was my second-to-last question......just trying to get my ducks in a row prior to my cut tonight....

1) The statment: If NAT control has been enabled on the ASA", does that terminology just refer to having applied a NAT 0 or NAT 1 command on ANY interface?

2) I'm still confused on some of the legacy config: The Inside/Outside interfaces have NAT/Global commands applied respectfully. However, the DMZ does NOT have a NAT command applied, but there are static commands for internet users to initiate access to hosts on the DMZ. So if NAT control has been envoked, then I would think that they would have need a NAT command on the DMZ interface to work. Certainly, applying the NAT command now on the DMZ will NOT affect (negatively) those static translations which already exist between the outside-to-DMZ(?)

I'm probably making more of this than I need to. You've certainly straghtened out for me the fact that the ASA will look for static translations first, then will look to policy NAT; therefore, I just need policy NAT for my new IPSEC transaltions.

Fredrico, Thanks for your time on this.

Mike.

mmertens · ‎05-13-2010

Frederico,

My conversion went great! Thanks for all the valuable input!!!

Mike.

Federico Coto Fajardo · ‎05-13-2010

Mike,

Very glad to hear that ;-)

Thank you for the rating.

Federico.