Hi Karnal,

Below is what I currently have in place for nats, which is why I requested using a second nonat 0 for the outside interface with a separate, unique acl for the remote users who don't require nating to external addresses. So the order that the acl's are applied has an affect, except nat 0 which always applies first. That is why my inquiry to have another nat 0, but have it apply to the outside interface. In this scenario though, the acl would only source the remote vpn 10 subnets and not the whole 10/8 range:

Existing nat definitions:

nat (inside) 0 access-list nonat

nat (inside) 5 access-list wirelessnat

nat (outside) 10 access-list remotenat

nat (inside) 15 access-list dynnat

Existing acl's and order of function:

access-list nonat line 1 extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0

truncated

access-list wirelessnat line 2 extended permit ip 10.1.19.0 255.255.255.0 any

truncated

access-list remotenat line 2 extended permit ip 10.1.57.0 255.255.255.0 any

truncated

access-list dynnat line 2 extended permit ip 10.0.0.0 255.0.0.0 any

truncated

The reason for the separate nat (inside) option is because I segragate the public nat ip's that each acl affects

In theory I should be able to use the existing nat 0 statement, and just apply it with the "outside" command and corrolate a separate acl to it for the remote user subnet. So the changes would include the following:

nat (outside) 0 acl-remotenonat

access-list acl-remotenonat line 2 extended permit ip 10.1.57.0 255.255.255.0 198.217.36.0 255.255.255.0

truncated

As I shared, in this case I would use the nat 0 command, but apply it to different interfaces (inside vs outside), and use different acl's for each.

I don't believe I can use a nat (outside) <0 because I cannot apply deny statements to any other nat acl's except nat 0.

What do you think?

Thanks,

-Scott

Two corrections on my last post:

1) I meant to say my the changes are additions to the existing configuration.

2) I meant to say I can't use a nat (outside) >0 because...(I said less that 0 and meant greater than 0).

Thanks!

Hi Scott,

It seems that the VPN clients pool is 10.1.57.0 and the clients are accessing the internet through this device. Is the network behind this device 198.217.36.0/24? If yes then, your thought is absolutely correct. The commands would be as following :

access-list acl-remotenonat line 2 extended permit ip 10.1.57.0 255.255.255.0 198.217.36.0 255.255.255.0

nat (outside) 0 access-list acl-remotenonat

Hope this helps,

Kamal

Thanks Kamal,

To clarify, my remote vpn users that terminate on the asa use 10.1.57.0. They access internal and internet sights.

For the external sights, they nat out a unique public addy. There are however other specific external sites like 198.217.36.0 that the remote users need to access without natting.

My goal is to use the nat (outside) 0 acl-remotenonat acl to achieve that request.

At the same time though, the nat (inside) 0 acl-nonat will continue to function for inside users connecting to the same 198.217.36.0 sites without natting (these currently work now).

I will be attempting this later tonight. Thanks again for your input.

-Scott

I applied a nat (outside) 0 acl remote-nonat to the existing configuration that has a nat (inside) 0 acl nonat and it worked. Thank you for the advice and the help!

-Scott