Hi all,
Some background: we have two inside networks, and two classes of users. Network B is a general-use network, Network A is a secure network. Both A and B are behind an ASA. Both classes of users can be physically connected to Network B, and both classes of users can reach B from the Internet via SSL VPN (AnyConnect, with Radius authentication and Group Policy authorization). But “special” users need to be able reach Network A, from either the Internet or from Network B, and either way they must authenticate. In other words, Network A treats Network B as untrusted, and being physically connected to B does not change the admission requirement.
We have an ASA endpoint with a public IP address. We use an internal network address as the endpoint for users on B. Special users are distinguished from others by a separate Group Policy set by Radius, and use the same VPN credential (which is what we want). Everything works now correctly, except for one problem: if a special user is outside, the neworks in the encryption domain (split tunnel network list) include routing traffic to B via the VPN (good), but if these users are physically connected to B and start a VPN session to get to A what then breaks is any traffic to B gets routed via VPN as well, and this isn’t the desired outcome (bad).
When setting up the tunnel groups (er, profiles) we had what seemed a similar problem with address pools, until we realized that the selection of an address pool to use could be “delegated” from the Group Policy to the profile. We have been trying to come up with a way to not have the split network tunnel list entirely based on the Group Policy, but from what we can tell there is no way to make the encryption domain based on anything other than the identity of the user (vs. some way to make at least some of the networks/routing dependent on what network the user is coming from).
Assigning multiple credentials for a user isn’t optimal, nor is having AnyConnect exclude the local LAN from routing in general. I don’t understand Radius enough to know whether multiple Class attributes for an identity is actually not allowed, or whether AAA just doesn’t repect them (we tried default group policy specification in the tunnel groups after configuring our Radius with them; we use a hosted service for this so it’s likely a no op as the same Group Policy was always chosen regardless of the tunnel used). And, we originally started trying to figure out if we could get clients on B to hit the external IP of the ASA and then authenticate there as if from the Internet to get to A - but that seems really “out of the box” and our network engineer said it was impossible).
We can probably add ACLs to the address pool the special users get to let them access B from their A addresses, but that doesn’t seem quite right either. I am, then, guessing the answer to the question on this post is “no”, but hoping there is another way to think about what we’re trying to do that is cleaner and that we have somehow missed. Any ideas are welcome!
