NAT with 3 Interfaces

[rwoerner1]

I wanted to see if something like this would work.

The existing config works fine and works like so:

access-list remoteT1_AL extended permit ip object-group remoteT1_NAT_local object-group remoteT1_NAT

global (local1) 30 10.3.90.55

nat (local) 30 access-list remoteT1_AL

This is across 2 local interfaces, because we have a P2P T1 to a client and they're super strict with the IP range they allow, so I have to NAT everything from local to local1. I just dump the IPs I need into the object groups and I'm good to go.

The problem that has just arisen, is we setup a VPN to a new office on the 'public' interface and the users there need to access this P2P T1 network. I want to try to do something like this (see below) and just dump those VPN IPs into the object groups. It didn't work needless to say. Problem is that I have them nat exempt for the VPN, but I obviously need to nat them for this connection. Also, I'm not sure if there is something inherent on the public interface that would make this infeasible to work. If anyone has any insight it would be much appreciated. Thanks in advance!

global (local1) 30 10.3.90.55

nat (local) 30 access-list remoteT1_AL

nat (public) 30 access-list  remoteT1_AL

-Rus

PS: Device is ASA 5510 w/ 8.2(1)11.

[rwoerner1]

I apologize, the reason why I didn't was because there aren't any ACLs pertaining to the nat (public) 0 and a few others. Someone else threw them on the config for no reason I suppose? I dropped that statement and a few others.

interface Ethernet0/0
nameif local
security-level 100
ip address w.w.w.w 255.255.255.0
ospf cost 10
!
interface Ethernet0/1
nameif public
security-level 0
ip address x.x.x.x 255.255.255.224 standby x.x.x.x
ospf cost 10
!
interface Ethernet0/2
nameif local1
security-level 100
ip address y.y.y.31 255.255.255.0
ospf authentication-key password
ospf authentication null
!
interface Ethernet0/3
description LAN Failover Interface
!
interface Management0/0
nameif management
security-level 100
ip address 192.168.1.1 255.255.255.0
management-only

route public 0.0.0.0 0.0.0.0 x.x.x.x 1
route local1 10.2.1.89 255.255.255.255 y.y.y.1

(there are a few other routes pointing to the remote T1 network but they're all the same syntax & gateway)

For the ACLs, there are about 800 so I'm going to go ahead and leave those out. Everything pertinent has been provided.

On a side note, I was going through the config line by line (I didn't set up this device so I don't know everything that was added) but I found the nat control statement. I'm not sure if this would affect going from a 0 int to a 100 int. I didn't quite understand the relevance. Could that be the problem? Thanks again.

[Jennifer Halim]

Sorry, but x.x.x.x, y.y.y.y does not help when we are trying to match the subnet through the NAT statement.

Also, please send through the following:

show run nat

show run global

show run static

And from the above "sh run nat" output, please share the access-list entries that you can see on the NAT entries.

If you can't provide any configuration details on the forum, you should just open a TAC case.

[rwoerner1]

object-group network INT_CHS
network-object 172.28.26.0 255.255.255.0

object-group network INT_NAT
description local IP group for INT NAT
network-object host 10.10.53.77

object-group network remotet1_NAT_local
description local hosts for remote T1 network NAT
network-object 172.28.26.0 255.255.255.0 (local interface subnet)

network-object 10.120.1.0 255.255.255.0 (remote VPN internal network)

object-group network remotet1_NAT
description local IP group for remote hosts NAT
network-object host 10.20.1.57
network-object host 10.20.1.85
network-object host 10.20.1.86
network-object host 10.20.2.40
network-object host 10.20.4.28
network-object host 10.2.1.89
network-object host 10.20.2.29
network-object host 10.20.2.30

crypto map public_map 1090 match address public_cryptomap_1090
crypto map public_map 1090 set peer 123.1.10.15
crypto map public_map 1090 set transform-set ESP-3DES-MD5
crypto map public_map 1090 set security-association lifetime seconds 86400

tunnel-group 123.1.10.15 type ipsec-l2l
tunnel-group 123.1.10.15 ipsec-attributes
pre-shared-key xxxxx

access-list public_cryptomap_1090 extended permit ip 172.28.26.0 255.255.255.0 10.121.1.0 255.255.255.0

access-list public_cryptomap_1090 extended permit ip host 10.20.1.57 10.121.1.0 255.255.255.0  (one of these for each host in the object group)

access-list nonat extended permit ip 172.28.26.0 255.255.255.0 10.121.0.0 255.255.255.0

access-list remoteT1_AL extended permit ip object-group remotet1_NAT_local object-group remotet1_NAT

access-list CHS_AL extended permit ip object-group INT_CHS object-group INT_NAT

nat (local) 0 access-list nonat
nat (local) 40 access-list CHS_AL
nat (local) 30 access-list remoteT1_AL

nat (local) 10 0.0.0.0 0.0.0.0
nat (public) 50 access-list remoteT1_AL outside

global (public) 40 192.168.11.25-192.168.11.28 netmask 255.255.255.0
global (public) 10 interface
global (local1) 30 10.1.90.55
global (local1) 50 10.1.90.159

no static nats

[Jennifer Halim]

Crypto ACL does not seem to match with the NATing that you have configured. Further to that, you also need to have NAT exemption for local1 interface which has not been configured.

You mention that 10.120.1.0 255.255.255.0  is the remote VPN internal network, but your crypto ACL has  10.121.1.0 255.255.255.0 as the destination. I assume the vpn tunnel is not even up yet at this stage?

Also I assume that object-group "remotet1_NAT" is routed towards local1 interface, right?

OK, let me assume this then:

Remote VPN peer LAN - 10.120.1.0/24

You would like to NAT traffic from the remote VPN LAN (10.120.1.0/24) towards local1 (object-group remote1_NAT) subnets to 10.1.90.159

So firstly: configure the NATing first:

access-list local1-nonat permit ip object-group remote1_NAT host 10.1.90.31

nat (local1) 0 access-list local1-nonat

I would leave the following in the configuration:

nat (public) 50 access-list remoteT1_AL outside

global (local1) 50 10.1.90.159

Secondly: configure the correct crypto ACL (and the peer VPN gateway needs to be configured with mirror image ACL):

access-list public_cryptomap_1090 extended permit ip 10.20.1.0 255.255.255.0 10.120.1.0 255.255.255.0

access-list public_cryptomap_1090 extended permit ip 10.20.2.0  255.255.255.0 10.120.1.0 255.255.255.0

access-list public_cryptomap_1090 extended permit ip 10.20.4.0  255.255.255.0 10.120.1.0 255.255.255.0

access-list public_cryptomap_1090 extended permit ip 10.2.1.0  255.255.255.0 10.120.1.0 255.255.255.0

Hope I haven't confused you.

[rwoerner1]

Thanks for the reply, they Crypto ACL doesn't match completely, because the remote VPN needs to access items on the local int as well as off of the local1 int. As far as leaving the additional hosts out I just figured it would be redundant to have 10 almost identical ACLs, sorry.

The tunnel itself is and has been working fine to the local, we have about 25 other VPN using the same ordered ACLs.

I made the changes, I'm just waiting to hear back from the guy at the other site. I'll let you know. Thanks again.