On my SG310, the first SSL VPN Profile I created was simply called 'VPN'. As long as you're a member of Active Directory groups "A", "B" or "C", this profile is for you, and you can access the internal networks (There are 2 networks - "main" and "test"). So this policy is pretty open.
Today I created a second VPN profile. Its purpose: if you're a member of AD User Group "D", you'll instead fall into this profile when you connect to the VPN. And this profile needs to be more restrictive in that you can only access a specific computer on the "test" network. Nothing else. Just one computer. And you should have no access to the "main" network.
I created an active directory user "msmith", stuck him into AD security group "D" and connected to the VPN.
When testing I expected that this user, once connected to the VPN, would ONLY be able to connect to this specific computer on the test network. But it turns out he can remote into any computer on the test environment network as well as the main production network.
I assumed that's because there is a firewall rule that allows all "VPN Pool (SSL)" traffic to access "Any-Trusted" networks. And no matter which profile gets assigned to you, you're still within that same VPN Pool. Is that correct?
So, higher up in the list of firewall rules I created a new rule that says Source = Group "D", Services = Any, Destination = main network, Action = Drop. Not 100% what I am trying to achieve but at the very least I now expect that when this user connects to the VPN, he may still have access to multiple computers on the test network but now he should not get ANY access to the main network.
Well this also does not work. Turns out this user can still connect to any computer on the main network, even when moving this rule to the top of the list.
So, how can I restrict user msmith so that when he connects to the VPN, he can ONLY remote into a specific computer on a specific network? Is there a way to assign a firewall rule or restriction to an SSL Remote Access policy? (Probably not, I think policies are additive and this block should be added somewhere higher up in the hierarchy)
This thread was automatically locked due to age.
