Route statement stopping Remote Acc VPN, maybe Policy NAT?

[jimmyc_2]

  I have one ASA with two inside networks, and two outside internet-capable interfaces.

The insides are InsideWebSurf, and InsideCritical.

The outside interfaces are OutsideToInternet and OutsideVPNonly.

The default route goes to OutsideToInternet.

Static routes go to OutsideVPNonly.

ACLs restrict InsideWebSurf to only go to OutsideToInternet.

InsideCritical can only launch VPNs on the OutsideVPNonly, so it can never websurf or do anything else but establish the VPNs.

So far, so good, that part works fine.

Now I want to allow Remote Access to VPN in through the OutsideVPNonly interface, and see the InsideCritical subnet.  Also, it should be able to bent-pipe onto the other VPN, and reach the remote VPN sites that InsideCritical can see.

The problem is I have to create a static route to the Remote Access PC (which goes out the OutsideVPNonly interface).

When I do this, things work.   But if the RemoteAccess PC roams to a new IP, I have to add another route statement.

Is there a way to Policy Nat my way out of this delima?

Thanks.

[Jouni Forss]

Hi,

This is not something that I have tried myself but might lab just to see hot it works.

I would presume that the main problem in your situation is the fact that the connections are coming "to the box" rather than "through the box".

Or have you tried configuring a Default Route with worse metric on the VPN WAN interface?

If that doesnt help I would imagine that you might have one option. This option requires however you to have perhaps 8.4 - 9.1 software level in use.

What you would have to do in this case is essentially

• Configure the VPN WAN interface with the actual default route to enable Remote Access VPN to work properly without specific routes.
• Configure a higher metric Default Route through the WEB WAN interface so that interface will also have a route to forward traffic to any destination address that is unknown to the routing table.
• Configure a NAT configuration for the WEB LAN to WEB WAN interface so that connections for any user behind WEB LAN destined to any destination IP address would be forwarded to WEB WAN interface and using its default route

The idea of the above is basically that we switch the active Default Route to the VPN WAN interface. We then use a NAT configuration to force ALL traffic from the WEB LAN to the WEB WAN. After the NAT has performed its part the ASA will check its routing table to forward the traffic using the higher metric default route pointing out the WEB WAN interface.

The basic NAT configuration format to forward all inbound traffic from the WEB LAN to WEB WAN could be done with the following configuration. (Reusing some configuration I have posted here before)

interface GigabitEthernet0/0

description WEB WAN

nameif WEB-WAN

security-level 0

ip address 192.168.101.2 255.255.255.0

!

interface GigabitEthernet0/1

description VPN WAN

nameif VPN-WAN

security-level 0

ip address 192.168.102.2 255.255.255.0

!

interface GigabitEthernet0/2

description LAN

nameif WEB-LAN

security-level 100

ip address 10.10.10.1 255.255.255.0

interface GigabitEthernet0/3

description LAN

nameif VPN-LAN

security-level 100

ip address 10.10.20.1 255.255.255.0

route VPN-WAN 0.0.0.0 0.0.0.0 192.168.102.1 1

route WEB-WAN 0.0.0.0 0.0.0.0 192.168.101.1 254

object network WEB-LAN

subnet 10.10.10.0 255.255.255.0

object network VPN-LAN

subnet 10.10.20.0 255.255.255.0

object network ANY-0.0.0.0-1

subnet 0.0.0.0 128.0.0.0

object network ANY-128.0.0.0-1

subnet 128.0.0.0 128.0.0.0

object-group network ALL

network-object object ANY-0.0.0.0-1

network-object object ANY-128.0.0.0-1

object-group network VPN-CLIENT-REMOTE

network-object 172.16.10.0 255.255.255.0

network-object 172.16.20.0 255.255.255.0

object-group network VPN-REMOTE

network-object 192.168.10.0 255.255.255.0

network-object 192.168.20.0 255.255.255.0

network-object 192.168.30.0 255.255.255.0

network-object 192.168.40.0 255.255.255.0

nat (WEB-LAN,WEB-WAN) source dynamic WEB-LAN interface destination static ALL ALL

nat (VPN-WAN,VPN-WAN) source static VPN-CLIENT-REMOTE VPN-CLIENT-REMOTE destination static VPN-REMOTE VPN-REMOTE

nat (VPN-LAN,VPN-WAN) source static VPN-LAN VPN-LAN destination static VPN-REMOTE VPN-REMOTE

nat (VPN-LAN,VPN-WAN) source dynamic VPN-LAN interface destination static ALL ALL

The above configuration essentially has the following

• 2 WAN interfaces
• 2 LAN interfaces
• 2 Default routes. The active one is for VPN-WAN
• Objects that define usefull networks for the purpose of configuring NAT
• NAT Configurations that force each LAN to use its own WAN interface for outbound access (using Dynamic PAT)
• NAT Configuration that does NAT0 / NAT Exempt for the networks on VPN-LAN and VPN-WAN

The important thing with such a setup would be to see that the NAT configurations order will play a pretty big role in the future. Notice that we enter the NAT0 configuration before the Dynamic PAT rule so it doesnt get overriden.

I would presume this would work but as I said I havent tested the mentioned setup. We usually either run a single WAN link on the ASA or use separate ASAs for Firewall and VPN purposes.

The NAT configuration could be changed a bit to make the future NAT configurations for the VPN interfaces easier. So the above configuration isnt the only option.

- Jouni

Message was edited by: Jouni Forss (added a NAT configuration for VPN to VPN traffic)

[jimmyc_2]

Thanks, I have to back-burner this for a bit, but will try to hit by next week.  jc

[Jouni Forss · Accepted solution]

Hi,

I would like to point out that the NAT configuration is probably something that Cisco would never suggest for a production environment. Atleast I presume so.

I wouldnt particularly suggest it as first option production environment either but just wanted to point out that this SHOULD be possible if you truly need to handle 2 ISP setup on the single ASA.

So if you are are trying to implement this to a production ASA with a lot of NAT configurations I would take the time to go through all the required changes to NAT configurations as just adding these new configurations might possibly cause problems.

- Jouni

[jimmyc_2]

Sound advice.   thanks.