Weekly Tech Tidbit – Doing Public/BYOD Wireless The Right Way

May 9th, 2019
Weekly Tech Tidbit – Doing Public/BYOD Wireless The Right Way

Bob and I have discussed over and over the need for improved public wireless configuration.   Some of you have gotten the message.  Sadly many have not.  As we approach the summer, let's get this fixed once and for all.

Here are a few design changes many of you need to implement:

If your endpoints in the district under your control must be considered the "wild west" in terms of patching and remote access, then your public/BYOD must be treated as a true war zone where nothing can be trusted.

To that aim the design principle is to keep absolutely everything about the inside of your network away from these users.  The exception might be if you have an on premise mail server with webmail or similar limited exposure resource.   VDI solutions like VMware Horizon View are good solutions to allow these devices inside in a safe manner.

To that aim we have to make some fundamental design changes to safely accommodate these public/BYOD users.

  1. Never use internal DHCP to service public/BYOD scopes.   Your normal DHCP should be configured with Administrator level credentials to allow DHCP to talk to DNS and do "Dynamic DNS (DDNS) updates.  This is where the name of the DHCP leased client shows up in DNS.  This forward lookup entry when combined with a clean corresponding reverse DNS PTR record allows client management systems like Microsoft SCCM Configuration Manager or the Dell KACE appliance to find your clients to do all those management functions.   With Public/BYOD we actually don't want any of those leases to register in our internal DNS.   It just makes it noisy.  Sally's iPhone is not relevant.  Worse we can have DNS poisoning where I name my phone DO-SERVER and have it erroneously advertise itself as an alternative address for the real DO-SERVER causing mass dysfunction.  *ALL* of this goes away simply by moving the scope and not registering the names.
  2. The follow up to #1 is simply not to point to internal DNS at all.   You need to do one of two things:
    1. Point these Public/BYOD scopes to some sort of Public DNS.  We would recommend pointing them at least to the free version of Cisco Umbrella (aka OpenDNS) so you at least get the first level of known malware sites blocked for these users.
    2. For those of you who have legitimate internal resources that these BYOD/Public devices need to access (i.e. webmail on an on-premise server or the VDI gateway into the district) the simplest thing to do for this is to stand up a separate DNS server that isn't part of the domain and exists on a Public/BYOD visible VLAN.   Put your 1-5 DNS records in there for  you and then point that to Cisco Umbrella.
  3. Many sites are going one step further and forcing users to authenticate to the public/BYOD network with their internal credentials - or even some public/social media credentials from someplace else in order to get wireless access vs. just accepting the EULA like you do going to many doctor's offices.
  4. The other thing I see constantly in the Paladin Sentinel console is DHCP scope exhaustion for many of your public/BYOD VLANs.  This generally is because your DHCP scopes are too small and your leases are too long.  We get the faculty or student walking by the cafeteria and picking up an address on the phone in their pocket.   To resolve this we need to do the following:
    1. Limit the lease times for these scopes to reasonable, small periods
    2. Create scopes that have large address spaces to avoid this issue.
    3. Also people forget that Microsoft DHCP has a hidden, built-in grace period of 4 hours.   That means that if you set a lease for 1 hour, the address will not be reclaimed and given out again for 5 hours (1 hour lease + 4 hours grace).  That is most of your academic day.  This leads to scope exhaustion.  There is a registry key to set for the entire DHCP server scopes to reduce the grace period to a more realistic period.   Since it must be applied to the server and not the scope, it is another reason to have completely separate DHCP server for public/BYOD.

So that is your assignment.  Make this happen and you will have happier public/BYOD users, cleaner internal DNS and less headaches over all.

None of this is hard and I am sure there are some items that need to be thought through in your particular setup.   We are happy to discuss this with you and make a plan to get this done once and for all.