We currently have 2 broadcast SSIDs a corporate Radius authenticated network and a guest which is open and has no local access. This is all working fine. We have a small use case where we may have a 'partner' on site for a period of time who will need access to a specific internal resource that is not accessible externally without VPN. This is a first, possibly only time and not sure how long it will be used. So I'm trying to avoid making huge changes to our existing setup if I can. If the partner is off premises they can access the resource via VPN, This is tested and proven. If the partner is on premises I'm trying to come up with a way to provide access to the internal resource without giving access to our entire internal network. I've thought of a couple of different ways. Using the VPN across the guest wireless runs into loopback issues with the firewall that I haven't been able to resolve, and think may not be 'fixable' I'm thinking that I could address this with a Radius authenticated SSID that has a layer 4 access control only allowing access to our DNS server, and the internal resource. I 'could' put this in the same vlan as our 'corporate' SSID and just restrict access at the AP. I'm sure this isn't the most secure way, but would only require a few minor changes on the Wireless. I've experimented with the Roles in ZD and see I can use Radius to 'put' the user to an ssid even if they click on the 'full corporate' SSID. Anyone have other thoughts on how to approach this. I'd like to avoid setting up an entirely new vlan, dhcp scope.... for what might be never used again. Thanks
Thanks for the suggestion. I tried 'cloning' my corporate SSID and then placing an ACL on it. It seems to have worked. Would have going the guest route just auto-setup the ACL's or does it provide more restriction. Obviously the time expiration, but I already have an 'AD' account created for him to access the internal resource so I can leverage that.
A guest network is essentially based off ACLs and then some. It presets some ACLs that prevent access to the subnets that your ZD and AP's reside on, with specific exceptions for talking to the ZD's captive portal.
The only thing "bonus" that it does is that it makes the ZD respond with a captive portal specific landing page if you attempt to talk to it, instead of a ZD login page. It's a mild deterrent to an attacker attempting to brute force your ZD login credentials.