Smoothwall and Meru Wireless Network

[tommylawson]

We have built a meru wireless network with smoothwall filtering and we are now experimenting with the best way to manage school owned windows and IOS clients and BYOD. Anybody got this sorted yet?

 

Our current issues revolve around...

Choosing which authentication method is used for each group of clients

Transparent and non-transparent proxies

Managing W7 Starter netbooks

Managing Ipad & Ipod Touches

Guest users

Edited January 9, 2013 by tommylawson

[drewp]

Setup a transparent proxy server with SSL cookie authentication in SmoothWall, working well for us.

 

I don’t think there is much management of personal devices that you could do. Meraki offer a free Mobile Device Management system which you could use to manage your school owned devices with.

[Homer]

We have WPAD forcing proxy settings into Windows laptops etc in our Boarding House (Meru wireless) but things like iPads need the proxy settings entering manually, as the network these things reside on has been isolated from the main network with ACL policies, breaking transparent authentication.

[RTFM]

We have 5 SSID's (Curriculum, iOS, BYOD, Admin, Guest) on our wireless (Ruckus) all on their own VLAN (makes it much easier for setting up locations, segregating traffic etc).

 

Curriculum is school owned laptops and windows devices (so all on the domain) which all pick up the non-transparent proxy settings from group policy.

 

iOS is for school owned iOS devices and is transparently authenticated against a location which we have setup a seperate filtering policy for (so we can get apps working easier).

 

Admin is for admins and we transparently filter that as a 'whitelist all'.

 

BYOD is for staff and KS5 personal devices (mix of phones, tablets, laptops etc) and this is transparently set to redirect to SSL login page (with session cookie), they get filtered appropriately to what they login as. We have basically said we won't support apps on the BYOD SSID, if they work they work, if they dont then thats unfortunate but we don't have the time to get every app working for every person. This is different on the iOS SSID which is why we filter it differently.

 

Just a quick insight into how we work, it is going well and to be honest, we couldn't think of many better ways to do it.

 

The issue with iOS devices (unsure if this has changed in a recent update) is that apps dont always pick up the proxy settings, some will ignore them and try to access the net directly, bypassing your filter if it isnt inline. Your also unable to lock down iOS wifi settings, so someone can just come along and turn off the proxy anyway. We found the best way to get this to work was to transparently filter the iOS devices, eliminating the need for the proxy settings to be used.....as i say, 'global proxy' might work differently which I believe can now be rolled out using MDM but even then, we've found most MDM solutions really dont work in the way we would want them to, and are expensive for what they do (AirWatch for example).

Edited January 17, 2013 by RTFM

[Tsonga]

We have 5 SSID's (Curriculum, iOS, BYOD, Admin, Guest) on our wireless (Ruckus) all on their own VLAN (makes it much easier for setting up locations, segregating traffic etc).

 

Curriculum is school owned laptops and windows devices (so all on the domain) which all pick up the non-transparent proxy settings from group policy.

 

iOS is for school owned iOS devices and is transparently authenticated against a location which we have setup a seperate filtering policy for (so we can get apps working easier).

 

Admin is for admins and we transparently filter that as a 'whitelist all'.

 

BYOD is for staff and KS5 personal devices (mix of phones, tablets, laptops etc) and this is transparently set to redirect to SSL login page (with session cookie), they get filtered appropriately to what they login as. We have basically said we won't support apps on the BYOD SSID, if they work they work, if they dont then thats unfortunate but we don't have the time to get every app working for every person. This is different on the iOS SSID which is why we filter it differently.

 

Just a quick insight into how we work, it is going well and to be honest, we couldn't think of many better ways to do it.

 

The issue with iOS devices (unsure if this has changed in a recent update) is that apps dont always pick up the proxy settings, some will ignore them and try to access the net directly, bypassing your filter if it isnt inline. Your also unable to lock down iOS wifi settings, so someone can just come along and turn off the proxy anyway. We found the best way to get this to work was to transparently filter the iOS devices, eliminating the need for the proxy settings to be used.....as i say, 'global proxy' might work differently which I believe can now be rolled out using MDM but even then, we've found most MDM solutions really dont work in the way we would want them to, and are expensive for what they do (AirWatch for example).

 

This was exactly what I was aiming for in my previous school and I couldn't work out a better way to do it. Do you also use the guest access through Ruckus?

[RTFM]

This was exactly what I was aiming for in my previous school and I couldn't work out a better way to do it. Do you also use the guest access through Ruckus?

 

We don't but we will be doing. It's easy enough for an end user (receptionist or someone) to login to the portal and print off some temporary keys (or 100 and have them saved somewhere)

[Mr_P]

Setup a transparent proxy server with SSL cookie authentication in SmoothWall, working well for us.

 

I don’t think there is much management of personal devices that you could do. Meraki offer a free Mobile Device Management system which you could use to manage your school owned devices with.

 

Make sure you use the cookie option as the other will timeout on you pretty quickly.

 

The login page you get works with most browsers, but we have issues with Safari with it. You can customize it easily.

[RTFM]

Make sure you use the cookie option as the other will timeout on you pretty quickly.

 

The login page you get works with most browsers, but we have issues with Safari with it. You can customize it easily.

 

Yeah it doesnt work with Safari on iOS devices, we have advised users to download Chrome

[ict_support]

If anyone has any android devices you will need to add the proxy in manually to get things like the play store working even if you are filtering using ident by location in smoothwall.

[Tsonga]

We don't but we will be doing. It's easy enough for an end user (receptionist or someone) to login to the portal and print off some temporary keys (or 100 and have them saved somewhere)

 

On a seperate VLAN?

 

How would smoothwall handle this if you are currently redirecting BYOD (so.....unautheticated IPs) to the SSL. Surley guest access would just be redirected there as well.....

 

...saying that, answering my own question, you could make that VLAN push out a different WPAD that would give out the port of a transparent level proxy, which would be assigned a filtering level.

[RTFM]

On a seperate VLAN?

 

How would smoothwall handle this if you are currently redirecting BYOD (so.....unautheticated IPs) to the SSL. Surley guest access would just be redirected there as well.....

 

...saying that, answering my own question, you could make that VLAN push out a different WPAD that would give out the port of a transparent level proxy, which would be assigned a filtering level.

 

Ruckus is handling generation of keys to the SSID, once connected your getting an IP we know about from our BYOD SSID and we'd transparently proxy that against a location (so the entire range for that VLAN would be set as a location in Smoothwall). That location would then either be filtered as something we already do (key stage 3 for example) which is fairly strict in terms of what you can access, or you setup a new BYOD filter which you can restrict / allow stuff to seperately from everyone else depending on what it is you are using it for at the time....

[ict_support]

On a seperate VLAN?

 

How would smoothwall handle this if you are currently redirecting BYOD (so.....unautheticated IPs) to the SSL. Surley guest access would just be redirected there as well.....

 

...saying that, answering my own question, you could make that VLAN push out a different WPAD that would give out the port of a transparent level proxy, which would be assigned a filtering level.

 

No sure what you are asking here? If they are on a separate VLANS the location is identified by the IP range of the VLAN, this is created as a Location in smoothwall for example 10.149.10.x to 10.149.10.x. Then setup as a transparent proxy and the method for authentication is a redirect to an SSL login page. No need for proxy settings in the device or messing with WPAD.

 

Is this how you are doing it RTFM?

[Ashm]

To be honest you shouldn't even need to create a separate location in Smoothwall for the VLAN unless you want to exclude specific filters etc. Normally you'd have the VLAN as another interface on Smoothwall. We have transparent proxy set up with no authentication on our Visitor VLAN (with unauthenticated requests set to use our Visitor web filter policy). Ruckus is set up for guest access mode and reception staff can login into the Ruckus portal (using their AD login) to generate and print off guest passcodes with instructions.

 

We have a separate BYOD VLAN on another Smoothwall interface using transparent proxy with SSL Login (Cookie mode authentication). This applies the filter policies the Student/Staff normally gets. This seems to work fine for me on iOS devices using Safari as long as you apply the iOS hotfix or use a signed SSL certificate.

[Tsonga]

To be honest I think I have simply hit my knowledge barrier. I'm not really asking questions from a practical point of view, more to further my own understanding.

 

I hadn't though of the location setup, but I understand how that would work. In terms of interface, would you make the VLAN have a different default gateway (as associated with the interface)? What does smoothwall have in place to handle separate interfaces?

[Ashm]

If smoothwall is set up to be the transparent proxy for the VLAN, then the Smoothwall IP for that interface would be the default gateway for the clients.

 

You could either use separate network ports on the Smoothwall server as separate interfaces (VLANs mapped to specific ports on the switch it connects to) or you set the port up as a trunked port on the switch with multiple VLANs and then use the "Virtual LAN Adaptors" option to create tagged interfaces in Smoothwall that map to the relevant VLANs.