Where does an SSL VPN subnet actually reside (considering routing)?

InquiringTech · ‎02-14-2023

Hi,

When you have AnyConnect SSL VPN set up on your FirePower ASA device for incoming connections, and a subnet is created for it, where does that actually "live"? Is it on the hardware firewall itself? We had a corporate IT team set it up a while back, but I'm having trouble routing it so it can access certain locations outside the original scope. I noticed there is not a separate VLAN for it on the switch, unlike the rest of the subnets. Is it basically in some special "DMZ" type zone on there with limited access to the local network, and requires certain settings on the ASA to fully work? For example to reach a network that is a further hop away from the LAN it is supposed to access? There are routes for it on the connected router and switch though.

The VPN subnet of 10.11.68.0 /24 is able to access our main LAN at 10.11.64.0 /24 okay for the most part. It can ping and RDP into devices. But we have a separate little wireless network attached to our LAN with a point-to-point link outside. The wireless router/bridge is at 10.11.64.17 on our LAN and goes to a 192.168.200.0 network outside. When using our normal LAN addresses in the 10.11.64.0 /24 range, we are able to both ping and access the device and reach that network behind it (via configured static routes). But from the VPN subnet of .68.0 we are not able to do either of those things, but can reach other things on the LAN, like servers at 10.11.64.15 for example. I did a Wireshark capture and there is no response when pinging (doesn't seem to know how to get there), and we can't access the web interface either. Not sure if it's because there are multiple hops, unlike if trying from the main local network.

Or is this likely some ACL on our network blocking this traffic? I also checked on the web GUI of the wireless router/bridge for the point to point network and I don't see anything there that would block this incoming traffic.

Not sure where to look for the problem exactly. As an added note, we also have split tunneling so that only traffic meant for our corporate network is routed through the VPN. Not sure if this may be impacting it if that 192.168.200.0 network is outside the scope and it doesn't know how to get there.

Rob Ingram · ‎02-15-2023

@InquiringTech traffic for your RAVPN IP pool merely needs to be routed to the ASA's inside interface. So if the parts of your networks do not have a route to the IP pool network, they will be unable to communicate. No VLAN needs to exist for it.

What routing have you configured?

Traceroute from part of the network that is unable to communicate with a VPN user to 10.11.68.x and determine the path it takes.

You could also run packet-tracer on the ASA to simulate the traffic flow and determine if there is a drop.

Have you checked your Split tunnel ACL to confirm 192.168.200.0/24 is included?

Lastly, do you have a NAT exemption rule from all your LAN networks to the VPN IP pool network, to ensure this traffic is not unintentially translated.

InquiringTech · ‎02-15-2023

Hmm, I don't even seem to be able to perform a successful traceroute from the main .64 LAN network to the .68 VPN pool. It just goes to the gateway of .64.1 and then shows asterisks afterward.

As for packet tracer on the ASA, it doesn't even seem to match actual behavior on the network. Because I can successfully ping from the VPN pool to other IPs on the main 68 LAN, although the ASA indicates the packet would be dropped by an implicit deny ACL rule.

On wireshark, when I try pinging the .64.17 where the bridge is from the VPN subnet, I get "Destination unreachable (port unreachable)". From what I'm reading, this may have to do with some kind of DNS issue? It seems to be trying to make a query there at 10.11.200.14. I also noticed all the addresses that I CAN successfully ping on the main LAN from the VPN subnet (like say 10.11.64.4) seem to be explicitly listed in the offsite DNS server at our corporate HQ. But I didn't know that pinging an IP address really involves DNS necessarily, I thought that is when you try to involve hostnames specifically. There is a workstation here, for example at 10.11.64.155) that is not listed on the corporate DNS and is not pingable from the VPN pool, but oddly I am still able to RDP into that. The 10.11.64.17, however, is both unpingable and unreachable via web interface. To be honest, I'm not even sure the inability to ping this local address is directly related to whether or not it can reach the 192.168.200.0 network behind it.

Rob Ingram · ‎02-16-2023

@InquiringTech sounds like a routing issue within your network that a device (the gateway for 64.1?) doesn't have a route to the VPN IP pool.

Check each device in the path and determine if a route exists. If you run a routing protocol across your network you could establish an adjacency to the ASA and advertise the VPN IP pool, so every device in the network running the routing protcol would know how to route to it.

Can you confirm all your networks are including the split-tunnel ACL and routed back to the ASA?

InquiringTech · ‎02-20-2023

Hm, yeah it's strange since those two subnets are still generally able to talk to each other.

Also, I never thought to run an actual routing protocol within our network like that.

I also added the 192.168.200.0 outdoor network to the Split-tunnel ACL scope, to no avail.

It's a bit of a weird network setup for me, as I'm used to something different. Let me see if I can get some example configs. In these examples I did change all the IP addresses for these things for security purposes, and these aren't the real ones.

Is there anything that stands out that may be impacting this problem? Trying to look for where it may be missing a route or something.

Thanks.

Rob Ingram · ‎02-21-2023

@InquiringTech you've no route for 192.168.200.0 on the ASA via the inside interface.

InquiringTech · ‎02-21-2023

Thanks. So I added a 'route inside 192.168.200.0 255.255.255.0 1.1.1.3' to the ASA config, but it didn't help so far. With that, you're only supposed to indicate simply the next hop, right, which in this case is the switch stack at 1.1.1.3? And then that switch is supposed to have its own route to that network, which it should as 'ip route 192.168.200.0 255.255.255.0 10.1.64.7'... But it's still not finding a path. I did a tracert while on the VPN pool to 192.168.200.5 and it was just * * * *

Hmm...

Rob Ingram · ‎02-21-2023

@InquiringTech not sure why you've got this route on the ASA, that is the RAVPN network which exists on the ASA itself. Remove it.

route inside 10.11.68.0 255.255.255.0 1.1.1.3

Does the wireless bridge network have a route to the RAVPN network? Traceroute from that network to the RAVPN network and see where it fails.

InquiringTech · ‎02-21-2023

The routes into that outdoor bridged network are basically one way. There isn't a way back from there into the main LAN (and thus also RAVPN). I guess we could set up static routes on individual devices there but that gets messy. The wireless bridge is a relatively simple set of TP Link devices, not actual proper Cisco routers where you can do much with the config. Maybe adding some kind of NATing device like an actual commercial router there is something to consider...

InquiringTech · ‎02-22-2023

Btw, I finally figured this out. It was in the configuration of our point-to-point wireless bridge, which was in AP Client Router mode (with one side acting as a WISP). For the return traffic, it was only looking for the specific IP or that local network (the .64.7 I mentioned), so by changing the subnet mask to 255.255.0.0 instead of 255.255.255.0, I was able to encompass the .68 RAVPN network as well.

Thanks for the help!