Google Expeditions on School Networks

Google Expeditions on School Networks

For those who don’t know Google Expeditions allows for Teachers to take students on virtual tours to places most field trips could never go. Teachers have the ability to direct the tour and keep kids engaged in this virtual reality world.

Expeditions is a peer-to-peer  (P2P) application that runs on iOS and Android devices.  The P2P aspect of the application presents many problems in most school environments. Schools have enterprise networks with segmentation just like networks in the corporate world. This segmentation presents problems related to discovery and communication for P2P applications like expeditions.  To get around the issues segmentation poses to Expeditions may retailers have put together very expensive kits that schools can buy.  Included in the kits are usually several android devices, cardboard or plastic VR viewers and a consumer grade wireless router.

In this post I'm going to give you some general guidelines and show you how to get around the big expense of these kits and the potential security threat they may cause.

First let's start with why the kits are bad ideas. Introducing any new devices into your environment could be difficult if you don’t have a way to centrally manage them.  You're going to want an MDM solution already in place with the necessary amount of licenses. Next the wireless router poses a potential security risk and could cause unintended network issue. Being that the wireless router is a consumer grade product there is no way of managing it on your enterprise wireless network and if these devices are configured incorrectly and plugged into the network you may find yourself with some DHCP issues that could be difficult to track down.  Weak or no security applied to the wireless interface of the router gives attackers or in this case students unfettered access to any VLAN this device may be plugged into.

If you want to reduce your potential headaches from these kits and save your districts lots of money, we need to figure a way to get Google Expeditions to work across VLANs on our wireless networks.  To do this we need to understand how Expeditions works. There are two main categories in Expeditions, Leaders and followers.  The lead device is always the teacher device and the follower is the student device. Lead devices need an internet connection to download expeditions (not the app but the tour you're going to take). Follower devices technically don’t need an internet connection they just need the ability to discover the lead device and make a P2P connection with it. For discovery Expeditions use Multicast DNS (mDNS) to discover other expeditions devices and setup a P2P connection with them using random ports.

Most students have their own devices iOS or Android and most schools have implemented some form of BYOD so let's take advantage this!

Alright now let's take a simple school wireless network and configure it to work with Expeditions.   In this environment we are going to say that all enterprise devices are on one VLAN (10) and all BYOD devices are on another VLAN (20).

Knowledge needed: DHCP, Access control lists, Multicast DNS and good understanding of your

wireless platform.

1. Choose a district owned enterprise device (or purchase a new one, iPads work great) that is always going to be the Expeditions Lead device. (This device does not only need to be used for expeditions but it always needs to be used when Leading an expedition. You can have several Lead devices)

2. Reserve an address in DHCP using the Expeditions Lead Device(s) MAC address. (Multiple devices require multiple different IPs)

3. Adjust ACLs to allow bidirectional communication between Expeditions Lead device(s) (these are the IPs you just reserved)  and Follower devices (this would be the entire BYOD subnet Vlan 20)

4. Enable multicast DNS (mDNS) across vlans (or SSIDs) that need to be able to participate in the

Expedition. (VLAN 10 and VLAN 20)

5. Add a new mDNS service “GoogleExpeditions” with service string

“_googexpeditions._tcp.local.”

6. Make sure the new GoogleExpeditions service is associated and can be seen by devices

After doing what's outlined we opened up minimal security holes to our network by allowing BYOD devices to only communicate with the IPs of the Lead devices instead of the entire enterprise subnet (VLAN). Schools I work with normaly select 1-5 devices to be a Lead device, this allows up to 5 different classes or Expeditions to run at a time. Having lots of devices as Lead devices could become a management nightmare if you need to create DHCP reservations for all of them.  If you need lots of Lead devices I would suggest placing them in their own VLAN and allowing your BYOD VLAN to communicate with it.

Below is a reference on how to add google expeditions mDNS to a Cisco WLC network.  You'll need to already have mDNS working in your environment and ACLs configured appropriately.

Controller > mDNS > General

 Add a new service

Master Services Database

Select Service: Other

Service Name: GoogleExpeditions

Service String: _googexpeditions._tcp.local.

Query Status: CHECK (enables the service)

LLS Status: CHECK (enables location for service. You must be connected to the same or surrounding APs  to discover)

Make sure to click Apply!

Now the service is created we need to associate it to our mDNS Profiles

Controller > mDNS > Profiles > (Choose your mDNS Profile to edit)

In my case I have two profiles to edit, Enterprise and BYOD

Services List

Service Name: GoogleExpeditions

Click Add

Last you need to Associate the mDNS profile to the WLAN(s) you want to be able to use Google Expeditions

WLANs > (Choose WLAN ID) > Advanced

Scroll to the bottom

If you're like me and have a single SSID for all devices that do 802.1x you can return the following RADIUS attribute to associate the mDNS profile to the end devices.

Cisco-AVPair

=

mDNS-profile-name=enterprise-mdns-profile

Thanks for reading, I hope this helps you in setting up your network for Google Expeditions!