VPN design refresh, multiple ASA/Headend but 1 shared IP pool

[JG1978]

Hello,

My organization is looking at a VPN refresh to accommodate all the work from home users. Today we have 4 separate ASA's that users connect to and each one has it's own VPN IP POOL given out by the ASA.

Now we are looking at changing the IP pool from the ASA to ACS/ISE/Windows DHCP server (undetermined yet). My question is how I setup routing for this.

Today our firewalls all have their inside interface IP as a subnet that lives on our Core switch so I don't have to do routing since the Core knows where each Subnet lives since they are directly connected. (Fake IP's listed of course)

ASA1 inside int = 10.10.10.1    ---> Core switch Vlan10 10.10.10.2

ASA2 inside int= 10.10.20.1    ---> Core switch Vlan20 10.10.20.2

So the routing tables on the ASA look like:

ASA1 route inside 0.0.0.0 0.0.0.0 tunneled --->10.10.10.2

ASA2 route inside 0.0.0.0 0.0.0.0 tunneled --->10.10.20.2

For the redesign I would like to use a big IP pool that is controlled outside of the ASA (ACS/ISE/DHCP server) that will work across all the ASA headends.

Is there an easy/right way to accomplish this without having a physical interface connected to the same subnet?

Would I still need the inside interfaces of every ASA to live on the same subnet pool as the VPN users or can they be a separate network and just utilize the "route inside 0.0.0.0 0.0.0.0 tunneled" command?

[Marvin Rhoads]

It's recommended to keep an IP pool per ASA. The pools can live on the respective ASAs or a separate DHCP server. The Cisco recommended best practice would be something like VPN load balancing on the client facing side with as many ASAs as you need to handle the load behind that.

You can read details about that and other solutions here:

https://www.cisco.com/c/en/us/td/docs/security/asa/misc/anyconnect-faq/anyconnect-faq.html#Cisco_Reference.dita_41edac65-48a1-4dec-ba68-edcd55629af3

One alternative if you are doing a dynamic routing protocol between your ASAs and your internal network is to allow th eASA to advertise the /32 host routes it installs when a new VPN client logs in. If the internal network learns those it would know which ASA to send the return traffic to. NOTE - I haven't tried this option but I think it should work. You should test it in a staging non-production setup to confirm.

[JG1978]

Thanks Marvin, Even with 1 pool per ASA, is it a requirement for the inside interface to be part of that pool?

I am struggling with configuring this without having the inside interface as part of the External VPN pool. 

I have an ACS server assigning an IP to a specific user (say 11.11.11.11) but the ASA inside interface is 10.10.10.1.

The VPN client connects and gets the correct IP and subnet mask and then picks the first IP in that range as its gateway. (11.11.11.1), at least according to route print.

There is no 11.11.11.1 on the ASA but rather that IP is on our Core switch/router and the ASA just has "route inside 0.0.0.0 0.0.0.0 10.10.10.2 tunneled" with the 10.10.10.2 being the Core as well. My understanding is the VPN client traffic should be able to reach the gateway of 11.11.11.1 but its just not working.

VPN Client (11.11.11.2)----> (outside)ASA(inside 10.10.10.1) ----> COREL3 switch with 10.10.10.2 and 11.11.11.1 IP's

 ASA route inside 0.0.0.0 0.0.0.0 tunneled 10.10.10.2

Shouldn't this allow the VPN traffic to pass right to the core switch and use it as the gateway?

[Marvin Rhoads · Accepted solution]

The core switch should not have the 11.11.11.1 address. It needs to know to return the 11.11.11.x traffic to the ASA. If it has a connected interface in that network then no static route or dynamic route can have a lower administrative distance than 0 (connected).

The VPN users can use the ASAs inside gateway on the core as their gateway as well. As long as the core can return the reply traffic to the ASA properly it will all work

[JG1978]

Got it thanks, I worked with TAC and it was the same response, we removed the 11.11.11.1 off the core and put routing towards the ASA for the subnet and it worked.

Thanks!

[Marvin Rhoads]

I'm glad to know the TAC had the same recommendation as I did. Happy it's working for you now.