06-18-2019 07:49 AM - edited 02-21-2020 09:40 PM
Greetings
We've recently moved from a flat /16 network to a managed network consisting of a few /24's. On the original network, our ASA's inside interface had an IP that was on the /16 and VPN connections were happy. With the managed network, the situation changed a little.
We introduced a 3850-48T-S into the network with L3 services. It hosts all VLANs and is running a DHCP server for each VLAN that requires it. Three VLANs are in question here. The first (100) has our network services (AD/DNS/Files/etc.), the second (200) has our workstations, and the third (500) is intended to be the landing zone for all VPN connections. The 3850 connects to the ASA on a dedicated port and is using a different subnet for this communication only. So to paint this picture, there are four subnets at play here:
10.0.10.x/24 = VLAN 100
10.0.20.x/23 = VLAN 200
10.0.50.x/24 = VLAN 500
10.0.254.x/29 = ASA/C3850 Communication subnet
(ASA = 10.0.254.2, 3850 = 10.0.254.3)
The design here was because we wanted the ability to conditionally route select VLANs to the internet, now and in the future, so we didn't think it wise to stick the ASA into a specific VLAN.
As it stands, the routing is correct in terms of inter-VLAN comms and getting these VLANs out to the internet and back.
The ASA AnyConnect was originally configured to use a local IP pool which sat in the original /16 subnet, and this worked fine. However, what we desire to happen now is that an incoming VPN request is given an address in the 10.0.50.x/24 subnet, which is on the 3850 behind the 10.0.254.3 address. If we use a local pool, an address is assigned to the VPN client, but they can't see any of the services or hosts on any of the aforementioned VLANs. I'm sure it's misconfigured, but if we attempt to use a DHCP pool for address assignment, the connection request times out as no IP can be assigned to the guest.
What am I missing here with this configuration?
Solved! Go to Solution.
06-18-2019 08:26 AM
I've corrected the issue, although through different means.
Relenting on the original scope, we decided to use a local IP pool on the ASA. We then NAT-exempted the addresses. We're now able to access via VPN.
06-18-2019 08:26 AM
I've corrected the issue, although through different means.
Relenting on the original scope, we decided to use a local IP pool on the ASA. We then NAT-exempted the addresses. We're now able to access via VPN.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide