Sanity Check on a VPN Design

[jsalmans]

Greetings all,

I've been asked to set up a secure desktop for one of our departments.  The desktop will need access to a few on premises resources such as DHCP, DNS, and AD but, otherwise, it has to be restricted to allow connectivity only to a specific website.

I can do this simply with a VLAN setup but this leaves open the possibility of a mistake being made somewhere in our core that would allow other devices to route or access that VLAN.

Instead, I started to think about doing a Pre-Logon and Always-On VPN connection and just leave the device connected to the main building VLAN.  This is something I've been meaning to implement anyways for a few other projects but I just haven't gotten around to it yet.

I'm trying to figure out the best way to go about this though and could use some input:

1. Is this overkill (i.e. just use a VLAN instead)?
2. If I use Pre-Logon and then it switches to the user context after logon, how do I keep it using the same restricted gateway instead of it switching the user to the more standard client access gateway?  Our portal has an existing staff config on... I'm assuming the Pre-Logon config would go on top but, if I put another config in after the Pre-Logon but before the general staff one, I'm afraid this will interfere with their ability to use the more standard VPN on other desktops.
3. Would the solution to #2 be to use a separate portal just for Pre-Logon devices?  That way, configs can be kept entirely separate.  If so, should the portal use a device cert profile or just the gateways?

Thanks in advance.

[BPry]

@jsalmans,

Personally I think you are adding a lot of complexity when you don't actually need to. If you are worried that someone else could make a configuration change that could effect this VLAN, why not simply setup the interface with an access-group and be done with it? You could allow access to whatever is needed and wouldn't have to worry about anything on your cores effecting this port in any way at all. 

[jsalmans]

@BPry it seemed like a good idea at first just from the security aspect of it... no matter what is done with this computer or upstream network config, it would always have encrypted traffic going directly to the firewall.  They could even move it to another network and it would still just work and be secure.

I agree that it seems pretty complicated now that I've started diving in to the config.  I may revise this and look back at the VLAN option although I still need to figure out all of the pre-logon/always-on VPN stuff for some of the other projects I mentioned.

[BPry]

@jsalmans,

This would have been a great test for that until you mentioned that you didn't want the user to inherit their access while on this machine. 

[jsalmans]

Yeah and I think the only way to do that is the separate portal.  We have two other use cases:

1. Locations off-site that have AD joined computers at them but aren't connected to our network (I don't know why they're domain joined but desktop management is outside my department).
2. Laptops used as wireless mobile clients in a particular building that transfer sensitive information... again this one could be solved at the network level by creating a network and hidden SSID with a PSK but we're trying to minimize the number of active SSIDs from any given AP.

With #1 a separate portal may not be necessary as the pre-logon connection is what is really important for the AD login.  After login, the VPN could be always on with SSO or On-Demand.

With #2 a separate portal may also not be strictly necessary since we're primarly concerned here with transfer of sensitive over the wireless segment.

That being said, it seems like having a second portal just for this kind of connectivity could really open some options for better control over the types of connectivity the same users have access to on other portals (i.e. one portal for general VPN client access, another one for pre-logon, etc.).

[OtakarKlier]

Hello,

Just a few ideas but first let me address this question from the original post:

1. If I use Pre-Logon and then it switches to the user context after logon, how do I keep it using the same restricted gateway instead of it switching the user to the more standard client access gateway?  Our portal has an existing staff config on... I'm assuming the Pre-Logon config would go on top but, if I put another config in after the Pre-Logon but before the general staff one, I'm afraid this will interfere with their ability to use the more standard VPN on other desktops.

For this I would have a seperate account for the users needing to access this machine. So either a different portal and zone, or policies restricting traffic based on username would help here.

For: 

1. Laptops used as wireless mobile clients in a particular building that transfer sensitive information... again this one could be solved at the network level by creating a network and hidden SSID with a PSK but we're trying to minimize the number of active SSIDs from any given AP.

Just have them VPN prior to transferring and data and then you are secure. One way I got around this problem was wireless users can only access internet resources. They need to VPN to access internal resources. However that solution is very politically charged.

I think you are on the corret path with multiple options.