IrritableTech

Yeah ours went live yesterday I think. Looking forward to telling my users.

Sounds good to me.

Mines primary. It's a subdomain and only used locally so it shouldn't cause any issues.

That's correct. Add the zone then create your A record for your smoothwall on your AD DNS server.

I don't use smoothwall, and it's been a while since I had a demo. I believe in the network section you should be able to create a virtual interface and you can also set a Vlan for it. Hopefully someone else can give you a better description. It sounds like your dhcp service is working, but because you've done it on another switch, it suggests it wasn't using VLANs. A correctly assigned virtual Nic on your smoothwall should work then.

Trunks are different depending on switch vendor. In HP world they are two links acting as one. In Cisco speak, they are generally links which carry data for more than one Vlan. Your smoothwall NIC is probably best set as interface 1 Vlan 1 and interface 1.1 Vlan 2. As a result you'll need to set your green p33 to tagged Vlan 1 and tagged vlan2. Not Untagged as I suggested before. Can you see if your smoothwall is getting a dhcp request and sending a response?

You should be able to add another domain to your AD DNS servers. I've done it for our wifi controller. So wifi.school.co.uk points to 10.1.2.100 for example. I did it for the same reason - we wanted a real world certificate for our wifi authentication page. The domain controller needs to be authoritive, but the domain doesn't need to be active directory integrated (I think from memory).

I think port 33 (sw green) should be Untagged Vlan 1 and tagged Vlan 2. But it depends on how you set up your smoothwall interfaces. Port 35 (sw red) should be Untagged Vlan 1 as should the port where your router connects. You could also think about setting up a 'unfiltered internet' Vlan (Vlan 3) which is only tagged on those two devices and ensure people can't find a way of avoiding your smoothwall box. This is unless you have other devices which need to get straight to the Internet and not use your smoothwall. Remember if you set up the Vlan on the end device (smoothwall, client, access point), the port should be Tagged, and if the end devices doesn't know about VLANs, the port should be Untagged.

Nothing else needs to be done to the APs if you follow what I've suggested above. You just need to configure your BYOD SSID to use Vlan 2. I presume your router is also connected to your core switch? Is it on another Vlan along with your 'dirty' feed? It looks like port 33 - your clean feed - needs to be Untagged Vlan 1 and tagged Vlan 2. Your smoothie will need a virtual NIC setting up for your Vlan 2 subnet. Did you say where your BYOD devices are getting dhcp from?

I'd go along the lines of the following following your thoughts... Core P1 tagged Vlan 1 & tagged Vlan 2 P2 Untagged Vlan 1 & tagged Vlan 2 P33 & P35, I'm not sure until you explain dirty and clean... Poe P1 Untagged Vlan 1 & tagged Vlan 2 P2 Untagged Vlan 1 & tagged Vlan 2 P16 tagged Vlan 1 & tagged Vlan 2 Everything else would probably be Untagged Vlan 1. Should point out Vlan 1 is best off not used for management, but many do without issue.

There isn't a live screen update, but if you use an inspector attached to a user and load the site, you'll see which parts are allowed and which are blocked once you run a report on them.

It is going to entirely depend on your environment, your infrastructure and your level of expertise. I've used Ruckus and Unifi extensively. Ruckus is a more rounded solution with pretty much everything working out of the box. Unifi is fantastic, but to do more advanced things you need to run radius. As others have said, if you go unifi, I'd get the pro APs. Either system, get a managed gigabit PoE switch you're familiar with.

I'd avoid it if possible, or keep it for one type of device only (ie. curriculum machines) and then tag the packets at the managed switch it uplinks too. Glad it is working for you.

Haven't used netgear for a while, but I'm fairly sure they follow hp. Untagged - this is generally used when the end device doesn't know about VLANs. All Untagged packets on a port will be tagged with the corresponding Vlan. Packets tagged with another Vlan will not be transmitted. Tagged - packets which have already been tagged by another device. So for arguments sake, you've got your switch and on port 1 is a workstation, port 2 a server and port 3 one of your APs you might do the following... Port 1 - Untagged Vlan 1. The workstation doesn't know or indeed care about VLANs. It's a background function. Port 2 - Tagged Vlan 1. You decide to set the Vlan on the server NIC driver (I do all my tagging at the switch though in reality). Port 3 - Untagged Vlan 1 and tagged Vlan 2. Your APs can talk to the controller, your curriculum traffic would be tagged by the switch, but your byod traffic can also pass over this switch port. Ports can only be Untagged in one Vlan (if the packet is not tagged, tag it in this Vlan) but can be tagged in many. Normally you would use different subnets for different VLANs. At the moment it looks like both your VLANs are in the same subnet.

Looks like a smooth solution and a decent set of instructions. Should help many. Thank you and well done.

When we had this issue in the past we used USBDLM: USB Drive Letter Manager - USBDLM Wasn't this fixed though in Windows 7?

Looks to me like that should work, yes. However I'd probably be a bit more specific about what I was letting my BYOD devices connect with. I'd probably just pop in the IP of my intranet server. Although you may have ACLs on your switches and ruckus controller sorting that potential issue.

Lightspeed have been pretty quick when I submit a mis-categorised URL to them - and generally follow my thoughts on which category it should be put in. However if BT Lancs are blocking the security.shortners category, and shorteners are being identified as shorteners, there's not a lot lightspeed can do. Having two products in the mix could only confuse matters further I guess. As I said previously - the vast majority of shortening services aren't a risk - the site to which the URL points is where the filtering should get involved.

Yeah, devices can only have one gateway. Ok, from reading things again, I think you are almost set. So your Smoothwalls IPs are 10.103.20.5 and 172.16.1.1 Your switches IPs are 10.103.20.133 and 172.16.1.2 Your DHCP servers IP is 10.103.20.11 and you can use your smoothwall as DNS - right? Leave your switches gateway as it is (10.103.20.5). Using the CLI (use PuTTY and telnet/shh into 10.103.20.133) conf t int vlan 2 name "byod" tagged (your list of tagged ports - I2,I4,etc.) ip address 172.16.1.2 255.255.255.0 ip helper-address 10.103.20.11 exit wr mem Ok, now to check your DHCP scope. Range 172.16.1.5-172.16.1.254 Scope options Router 172.16.1.1 DNS server 172.16.1.1 Ensure your ruckus wireless lan has vlan 2 set the ACCESS VLAN field. To explain. Your clients connecting to the BYOD vlan will broadcast asking for an IP address. Your switch (172.16.1.2) will relay this request to your DHCP server (10.103.20.11). Your DHCP server will chose a suitable IP address based on which network the original request came from (172.1.1.*) and send the address via your switch (there a bit more to it, but...) The client will receive the DHCP lease which will include a gateway - the IP you have already added to your smoothwall and created a transparent proxy. So the switches gateway is the smoothwalls curriculum IP address, as are your curriculum devices, but your BYOD devices are given an alternative gateway/router by your dhcp server. All devices routing where they should, but no device with more than one gateway set. Unless I've missed something (which is always entirely possible) I think that should do it?

I wouldn't rule out lightspeed. I'm not aware how CLEO have implemented the product, but it can be completely controlled by you either by having a rocket on site, or a correctly configured tiered system. On another note, what issues do you have with URL shorteners? Surely it's the final URL you're filter needs to be interested in, rather than the method of getting there?

Are you running the smoothwall as a proxy?

It's down to where the request originates from. If the request for a DHCP lease comes from your router 10.*.*.* address, that's the scope where the DHCP server will assign it from. If the request comes via the routers 172.*.*.* address, then DHCP will reply with a 172.*.*.* address. As long as you have all ports correctly assigned, and the vlans and two scopes set up correctly, it'll just work. The example below assumes your DHCP server is in the same VLAN as you curriculum machines. You could create another servers vlan and pop your DHCP server in that vlan. If you do, you'll need to add an ip helper-address into the curriculum vlan, so they can get DHCP leases as well. For example... vlan 5 name "Curric Network" untagged B1-D24 ip address 10.0.5.254 255.255.255.0 exit vlan 10 name "BYOD" tagged A1-A6 ip address 172.16.10.254 255.255.255.0 ip helper-address 10.0.5.1 exit I remember the first time I did this, it surprised me how simple it was.

Yeah this is easier than it seems sometimes. You need something like this in your switch config... vlan 10 name "BYOD" tagged A1-A6,Trk1-Trk4 ip address 172.16.10.254 255.255.255.0 ip helper-address 10.0.1.1 exit Then you create a DHCP scope on your windows DHCP server (10.0.1.1)... Scope: 172.16.10.1 - 172.16.10.253 Router: 172.16.10.254 DNS: 10.0.1.1, 10.0.1.2 Because the DHCP server gets the request via the router it allocates an IP address from the same range.

I got two for Christmas presents on Thursday expecting stock issues - haven't had a chance to give them a go yet. We doubled up our vouchers and also got two cases which were included in the offer.

The school must disclose this to the ICO, firstly. As others have said, it may trigger an audit. While you are waiting for their response, start creating a new working practices document which documents the correct procedure for sending out mass emails. Having extra measures and showing the ICO rep that you are learning from mistakes will help I'm sure. Google Apps for Education is covered under the Safe Harbor agreement as stated by others. Your ICO statement should reflect this though, explaining that data may be transferred to other countries. Again, this is something the ICO rep should pick up on if it hasn't been done. The LA representative is overselling their (presumably preferred) option. This could have happened on any email platform, and no system is able to reliably recall 100% of messages. For those that are asking, the biggest deployment of Google Apps I'm aware of is Norfolk County Council who has given access to all school staff and students. About 250,000 accounts when I discussed it with them a couple of years ago.