Guest VLAN (ahead of guest wireless)

[sonofsanta]

We don't have the money to upgrade our wireless at the moment, but there's nothing stopping me doing the groundwork now and giving sixth form access via LAN cable for their laptops in the common room.

 

So: I want to set up an entirely separate guest VLAN, wholly segregated from the rest of the network. It'll be routed at the core, and the only other device on the VLAN will be a Smoothwall SWG-1200 doing transparent filtering (i.e. it will be the default gateway).

 

The SWG can't do DHCP - only the UTM does that, and I don't want to pay the upgrade just for DHCP as it ain't cheap. So I could set up a virtual DHCP server inside the range, or I could do it via the core switch, a HP 5800 (Comware 5). Both are zero cost, essentially; which is better? Would the switch doing DHCP interfere with the other VLANs where it relays to the domain controllers? Would a server on the range be an additional vulnerability in a way, as it would be hosted on the same virtual infrastructure as everything else? All else being equal the server would at least be easier to use when it comes to investigating leases etc. (as techies will need to do it as well, not just me).

 

I'm also not certain how I'd go about segregating the VLAN off completely. Routing is static on the switches (not all of them supported OSPF and such, static was the lowest common denominator - works fine, though, so I'm not too concerned); can I use that to keep the traffic contained inside the guest VLAN?

 

TIA

[DMcCoy]

So: I want to set up an entirely separate guest VLAN, wholly segregated from the rest of the network. It'll be routed at the core, and the only other device on the VLAN will be a Smoothwall SWG-1200 doing transparent filtering (i.e. it will be the default gateway).

 

Why routed? Just don't give the vlan an ip, and drop a Smoothwall interface/vlan into it as the only way out.

 

I'm also not certain how I'd go about segregating the VLAN off completely. Routing is static on the switches (not all of them supported OSPF and such, static was the lowest common denominator - works fine, though, so I'm not too concerned); can I use that to keep the traffic contained inside the guest VLAN?

 

ACLs to block or as above.

 

For DHCP, switch DHCP is usually pretty terrible, the *HP* Procurve stuff doesn't even have a dhcp server. Remember if you use an MS DHCP server you need to have CALs somehow. A linux vm in the vlan would do.

[sonofsanta]

Why routed? Just don't give the vlan an ip, and drop a Smoothwall interface/vlan into it as the only way out.

 

I meant routed at core as in defined at core, with other switches just having the VLAN to tag/untag, as it's a VLAN that will have ports all over. I am lax with terminology, I fear.

 

ACLs to block or as above.

 

For DHCP, switch DHCP is usually pretty terrible, the *HP* Procurve stuff doesn't even have a dhcp server. Remember if you use an MS DHCP server you need to have CALs somehow. A linux vm in the vlan would do.

 

We'd have the CALs through EES - I think. I suppose that only provides device CALs for school owned devices though, doesn't it? And by definition wouldn't apply to guest access. Do you really need CALs solely for the DHCP role? Seems a bit extreme of them.

 

Ubuntu should be able to do DHCP, right? Pretty sure that's how fog works, and we have that running on Ubuntu.

[DMcCoy]

I meant routed at core as in defined at core, with other switches just having the VLAN to tag/untag, as it's a VLAN that will have ports all over. I am lax with terminology, I fear.

 

 

 

We'd have the CALs through EES - I think. I suppose that only provides device CALs for school owned devices though, doesn't it? And by definition wouldn't apply to guest access. Do you really need CALs solely for the DHCP role? Seems a bit extreme of them.

 

Ubuntu should be able to do DHCP, right? Pretty sure that's how fog works, and we have that running on Ubuntu.

 

Any linux/unix should be fine for dhcp/dns.

 

It's not been updated yet http://download.microsoft.com/download/6/8/9/68964284-864d-4a6d-aed9-f2c1f8f23e14/Assessing_Windows_Server_Licensing.docx but yes, for dhcp/dns cals are required.

 

People often forget ovs also only includes student laptops if they are *pooled* and not assigned to an individual.

[m25man]

You could plumb in your own edge router on the Guest VLAN to handle the DHCP and ACL, deliver the WAN port to the smoothwall.

 

Something like a Mikrotik

RouterBoard.com : Products will do the job nicely without over complicating the topology.

Bring the VLAN all the way back to the Core connect the edge router in line with the smoothwall.

These things are great for this type of segregation designed for WISP use but that's effectively what you want to do, be a WISP for your guests isn't it?

[Boredguy]

For our BYoD solution for staff and governors, we setup a Ubuntu VM with 2 network cards.

1 Network card was assigned to the vLan for the BYoD, and the 2nd was set to our normal address range.

We then configured DHCP on that server to give out an address, with the gateway being the Ubuntu box and the DNS server being our upstream address for our ISP.

 

We then setup iptables rules to redirect ports 80, 443 and 53 from NIC1 to NIC2. It's been working nicely on our Wifi (since all our Netgear AP's can support different vLan for each SSID and all our Netgear smart switches are vLan enabled)

We tag the port on the switch that the Access Points are connected to as T for the BYoD vLan, and the same for the uplink port.

 

The same setup is also working nicely for our test of Bluesocket Wireless (although I did have to update the network interface for the Bluesocket VM to ensure that the NIC could see all vLans in VMware)

[sonofsanta]

@m25man - if I can get away without spending any money, I'd prefer to all my budget has been sucked into capital projects this year.

 

For our BYoD solution for staff and governors, we setup a Ubuntu VM with 2 network cards.

1 Network card was assigned to the vLan for the BYoD, and the 2nd was set to our normal address range.

We then configured DHCP on that server to give out an address, with the gateway being the Ubuntu box and the DNS server being our upstream address for our ISP.

 

We then setup iptables rules to redirect ports 80, 443 and 53 from NIC1 to NIC2. It's been working nicely on our Wifi (since all our Netgear AP's can support different vLan for each SSID and all our Netgear smart switches are vLan enabled)

We tag the port on the switch that the Access Points are connected to as T for the BYoD vLan, and the same for the uplink port.

 

The same setup is also working nicely for our test of Bluesocket Wireless (although I did have to update the network interface for the Bluesocket VM to ensure that the NIC could see all vLans in VMware)

 

This sounds like the sort of route to take - multiple NICs with VLAN tagging is do-able in HyperV, and it'll all be free and easy to do. I'd set the default gateway to the Smoothwall for the transparent filtering but other than that I reckon I could follow that set up fairly easily.

 

When you talk about iptables for NIC1 to NIC2 - which NIC is which? NIC1 in the BYOD range and NIC2 on your internal network?

 

Infact, thinking about it - is an internal address even necessary? I could get access to the server by SCVMM, so wouldn't necessarily need an internal IP for administration. I could just segregate it entirely, couldn't I?

[rob_coles]

Upgrade your smoothwall to the edition with firewall. It has dhcp etc.

 

We have one network card sat on guest vlan doing dhcp + default gateway.

We have ours auth via radius using network username & password. The smoothwall acts as bridge & firewall.

 

Regards

 

Rob

[sonofsanta]

Upgrade your smoothwall to the edition with firewall. It has dhcp etc.

 

We have one network card sat on guest vlan doing dhcp + default gateway.

We have ours auth via radius using network username & password. The smoothwall acts as bridge & firewall.

 

Regards

 

Rob

 

The SWG can't do DHCP - only the UTM does that, and I don't want to pay the upgrade just for DHCP as it ain't cheap.

 

 

We don't need the rest of the features of the UTM platform, and I don't want to pay that increase in costs solely for DHCP which can be done free by another method. A single VM handing out addresses isn't a great deal of complication and I'm happy to go that route to save money where I can. I need to accomodate the growing monster that is printing costs, after all... /doing finances right now

[Boredguy]

NIC1 is assigned to the BYoD vLan and IP range

NIC2 is assigned to our admin vLan and IP range (since we only use that pipe for incoming VPN traffic and if our fibre internet connection drops we only have the curriculum range on the ADSL backup circuit)

 

We have upstream transparent proxy, so with the IPtables, the Linux box is just acting as another router.

 

I admit it might not be the best solution, but it works and cost us nothing but time.

[sonofsanta]

NIC1 is assigned to the BYoD vLan and IP range

NIC2 is assigned to our admin vLan and IP range (since we only use that pipe for incoming VPN traffic and if our fibre internet connection drops we only have the curriculum range on the ADSL backup circuit)

 

We have upstream transparent proxy, so with the IPtables, the Linux box is just acting as another router.

 

I admit it might not be the best solution, but it works and cost us nothing but time.

 

Thanks - sounds like I could just use the one NIC for the DHCP in the BYOD range, and then have the Smoothwall in on a second interface directing everything up to the internet. Cheers!

[Duke5A]

Our guest network is setup exactly the same with: an Ubtunu VM with two NICs, a VLAN with no IP information, one NIC in that VLAN with the other in the DMZ on our firewall. It works, but HTTPS is essentially broke. Everywhere I've read states that you can't transparently proxy HTTPS cleanly without being able to install a cert from the proxy onto the client device. The SSL bump feature works in Squid, but without the cert being installed on the client device HTTPS errors are constantly thrown in the browser. It's basically a man-in-the-middle attack.

 

The only workaround I've been able to come up with is setting up a captive portal on the proxy with instructions directing users to manually put proxy settings on their device. The HTTPS errors go away after doing this, but it is no longer transparent.