Opendium_Steve

They do allow it. I'm afraid I don't know who you need to contact though.

Typically you would have IPv6 and IPv4 running at the same time on the same network - all the machines would have both an IPv4 and an IPv6 address (this is known as a "dual stack" setup). You need IPv6 to access IPv6-only services on the internet. At the moment there are very few in the West (quite a lot in Asia though), but with IPv4 addresses getting scarce they will become more commonplace - how long that takes is anyone's guess. I agree that there's no immediate pressure for schools to adopt IPv6, but it's probably a good idea for new kit to be "IPv6 ready" lest you end up having to upgrade lots of stuff if the pressure appears earlier than you expect.

Linux supports IPv6 NAT these days. Not sure if there are any friendly UIs to drive it though.

That's a good point that I hadn't considered - less of an issue for internet-facing firewalls, which don't have to deal with vast bandwidths anyway, but certainly something to think about with respect to layer 3 switches that are handling 10Gbps links. High bandwidth routers have dedicated hardware for doing IPv4, but some (usually older) devices do software routing for IPv6, which will be significantly slower. Servers also have similar problems, although to a lesser extent - network cards often have dedicated hardware for handling IPv4, but might not for IPv6.

Ouch, £8-10k seems way too much for 150 kids IMHO. Do Smoothwall just have a fixed price point for secondary schools rather than adjusting their prices by number of users?

IPv6 NAT does exist... but it's a terrible idea for all the same reasons IPv4 NAT is a terrible idea. So we have 4 types of NAT: NAT44 NAT46 NAT64 NAT66 NAT44 is normal IPv4 NAT - you translate an IPv4 address to another IPv4 address. e.g. rewriting the source address so you can have multiple machines appearing to share a single address when connecting to the internet, or rewriting the destination address to create a port forward. The whole reason NAT44 exists is because there aren't many IPv4 addresses, so if you can hide a bunch of machines behind a few addresses then you can conserve them. With NAT46 you translate an IPv4 address to an IPv6 address so that an IPv4-only machine can connect to an IPv6-only machine. This can't be used to allow an IPv4 machine to talk to the IPv6 internet at large, since that machine has no way to tell anything what IPv6 it wants to connect to, but you can use it to map a specific IPv4 destination address to a specific IPv6 destination address. To be honest, it's really not that useful. NAT64 is the opposite of NAT46 - you can use it to allow an IPv6-only machine to connect to an IPv4-only machine. Generally you would route an entire /96 IPv6 prefix at your translator and encode the 32 bit IPv4 address you want to connect to in the last 32 bits of the IPv6 address. Not *that* useful since you're probably far better off dual-stacking your network and giving all your machines both v4 and v6 addresses. NAT66 is basically the IPv6 version of NAT44. You can either use it to hide a bunch of machines behind a single IP address, or more usually you'd use it to translate the prefix whilst leaving the right-hand-side of the addresses alone. Prefix translation is useful as a stop-gap measure for the "I've just changed ISP" situation, and for load balancing between independent connections. The problem with NAT (in any form), is that it causes a lot of problems for peer-to-peer systems, such as VoIP phones, etc. Through my whole professional career, my experience has always been to avoid NAT wherever possible - it may solve some short term problems, but it often comes back to bite you repeatedly. Prefix renumbering when you change ISP shouldn't be a _big_ problem, so long as you do address autoconfiguration wherever possible rather than manually addressing everything. I'd agree with that - I think the networking industry has had a head-in-sand approach on all sides. As you've mentioned, training isn't up to scratch; device manufacturers have been very slow to introduce support (often citing "well no ISPs offer IPv6" as an excuse); ISPs have been very slow (often citing "well no network devices support IPv6") and there's a general lack of awareness. I think my concern isn't so much that people aren't rolling out IPv6 capable networks at the moment, it's that people are still buying equipment that doesn't have any support without any consideration for whether they might need to migrate within the expected life of the equipment. The fun is going to start when some killer IPv6-only application that everyone wants appears and all the network admins have to drop everything to make it happen to please the bosses who demand it.

I've been watching ARIN's IPv4 inventory dwindling over the past few weeks... https://www.arin.net/resources/request/ipv4_countdown.html ARIN services North America and RIPE NCC (which services Europe) ran out of IPv4 addresses 3 years ago. None of this is going to directly affect any end-users right now, but ARIN running out of addresses will mark yet another step towards a move away from IPv4. I'm in the middle of writing a blog article to discuss this, so I'm wondering how many of you have thought about IPv6 support on your networks?

Why do Smoothwall alternatives require a Layer 3 switch? A lot of schools are switching to a routed infrastructure with a core layer 3 switch these days, and there are certainly a few good reasons to do this, but we certainly don't require it. Usually the setup we'd recommend is either: 1. A flat wired network, separate VLANs for wifi (network backbone is made up of layer 2 VLAN-capable switches): - Put each Wifi network on its own VLAN. - Put the whole wired network on a single VLAN. - Connect the filtering server to a VLAN trunk, with an IP address for each VLAN. - All of the devices on the networks use the filtering server as their default gateway and it routes between the VLANs. Machines on the wired network can obviously talk to each other since they're on the same VLAN, use the filtering server's firewall to control access between VLANs (e.g. restrict access between the wifi networks and the wired network. Alternatively: 2. A routed wired network, separate VLANs for wifi (layer 3 switch required): - Put each Wifi network on its own VLAN. - Split the school into multiple networks, a core layer 3 switch to route between the wired networks. - Connect the filtering server to a VLAN trunk, with an IP address for each VLAN. - All of the devices on the wired network use the layer 3 switch as their default gateway. - All of the devices on the wifi networks use the filtering server as their default gateway. Machines on the wired network can talk to each other by being routed through the layer 3 switch, use the filtering server's firewall to control access between Wifi and wired. The reason for using a layer 3 switch for option 2 is simply that wired traffic is often high bandwidth and doesn't need much access control, so a fast layer 3 switch is best for this whereas wifi traffic is lower bandwidth and does tend to need better access controls. It sounds like the first option would be best for you, and closely matches what you already do. It certainly doesn't preclude upgrading to a routed network at a later date either. If you do decide to upgrade to a routed infrastructure, we've found that HP switches are by far the best - you can certainly save up-front costs by getting a cheaper brand, but the pain and downtime associated with managing badly behaved switches isn't worth it.

For an Internet gateway, is there any reason to support 10Gbps? Its not as if many schools are likely to have 10Gbps internet connections any time soon...

I've tested against some DNS servers that I *believe* are the resolvers the LEA forwards to and they do indeed seem to work, so I'm not going to place the blame on the SWGfL. That said, the LEA haven't actually told me the IP addresses of the upstream resolvers, so I can't be sure. To be honest, I was pretty thrown by "we don't know what port DNS would use"... I would _hope_ that anyone running a WAN would understand this stuff, but I'm not seeing much evidence of it at the moment.

Well this still hasn't been resolved and I'm not holding my breath at the moment... A suitably anonymised blog article describing the issues: Steve's Blog: Ranting about LEA Network Administrators

Seems surprising - we've never needed to set passwords on our certificates. Maybe it's because Smoothwall are using a PKCS#12 certificate - we use PEM format...

Absolutely. We have an SLA that documents what the limits are so that everyone knows where they stand, but in reality we're pretty flexible and would waive the limits if there is genuinely a bug in the product. I wouldn't trust anyone that tries to "charge" you for dealing with bugs in their own product - after all, where's the incentive for them to improve things if they are benefiting from the problems! Also, the line between what is a problem with the product and what is a bug in third party software is often pretty fuzzy anyway, so you usually have to err on the side of caution and troubleshoot things that you're pretty certain aren't your problem.

I'm going to throw my 2p in here from a supplier's perspective (you may or may not agree with it, but I'd be interested to hear your reasons either way We used to give everyone unlimited support, but ended up changing our support levels a couple of years ago because we thought it was fairer for everyone. It boils down to this: some customers are very self-sufficient, take the time to learn the product and therefore don't ask for a lot of support. On the odd occasion those customers find they have a problem and ask for support, they are interested in learning how to do whatever it is they're asking for support for, so that they don't need to call next time. On the other hand, some customers call for support for every little thing, and often call about the same thing time and time again instead of learning to do it for themselves. We also get support calls that are almost completely unrelated to the product because we're often the first people on the list of people to call when "the internet is down" (even when it's only "down" for a single device and the rest of the network is working fine). Now, one of our big things is that we're pretty good at technical support (we don't do "first line", "second line", etc - the first person you talk to is always pretty technical, this isn't the cheapest way of doing things but it does seem like the best way to me), so we want to support both of these types of customers. Of course, everyone is busy and can't necessarily dedicate the time to learning every system on the network or solving all the problems themselves - neither type of customer is taking a "wrong" approach. But we thought it was unfair for the customers who had swallowed the cost of learning to support themselves to subsidise those who wanted a lot of support time from us instead. In the end we hit a compromise by splitting our support into 2 levels (standard/advanced). The "advanced" level is what we were always doing for everyone - unlimited email and phone support, also troubleshooting stuff not directly related to the product. The "standard" level places a limit on the amount of phone support time each month - this means that the people who don't need much support get a lower price than we could otherwise offer. A lot of thought went into setting the "standard support" limits - we analysed several years of our phone records and chose a limit that would only impact a few customers that we felt were using far in excess of the normal amount of support time. The limit is just the amount of time spent on the phone, not the time spent doing diagnostics, etc., non-urgent stuff can still be done by email without any limit and we give new installs a period of "advanced support" during the bedding in period since this is when everyone is going to need it, no matter what their approach. I guess it often looks like support limits are about penalising people who need a lot of support, but I've always viewed it as reducing the costs for those who don't (so long as the limits are set fairly). Do folks here think it's a bad idea?

Exposing a recursive DNS resolver to the outside world is a very bad idea - not only does it mean you can be used as a DDoS amplifier, but it also opens you up to the possibility of DNS poisoning to redirect your own users to malicious websites. As always, make sure you understand which services you're exposing to the internet, and close off any you don't need.

Already discussed here: http://www.edugeek.net/forums/internet-related-filtering-firewall/157004-youtube-schools-how-do-you-signup.html

Since this thread has popped up again and I've got some spare time this afternoon, I've answered a bunch of old comments since I think they're still relevant and SSL interception (along with the advantages and disadvantages) is still not well understood. IMHO your ICT usage policy (which your staff and students agree to) should state that internet traffic may be automatically monitored and that this may include interception of encrypted communications. Most filters would let you set different policies for the staff and students, so you could disable SSL interception for the staff. Obviously you need to weigh up the pros and cons and make a policy decision on exactly what/who you want to intercept - may involve explaining to non-technical policy makers exactly what's going on and why. I'm not a lawyer, but I would think that for services that the school itself does not subscribe to, T&Cs can only apply to the end users of a service, not a "man in the middle" such as the school or LEA running an intercepting proxy. For services that the school does subscribe to (e.g. Google Apps for Education), the T&Cs would apply to the school, but I would be surprised if the likes of Google care whether you're snooping on your own Google Apps traffic (I've not checked their T&Cs though). I would hope that filters would exclude banking sites by default - ours certainly does, and as other people have mentioned, I believe the SWGfL only intercept Google for the time being. Depends on how your web filter works and what's on the web site. Consider the following address: https://www.example.com/games If you don't intercept the traffic, the web filter knows that the user connected to "www.example.com", but there is no other information available. If you intercept it then the filter also knows that they accessed "/games" within that site, and can analyse the contents of the web pages. So, if you know that the whole of "www.example.com" is good or bad you can choose to allow or block it without doing any interception. If you know that it's mostly good but there's one specific section you want to block (e.g. maybe you want to block the games section of example.com during lesson times) then you're going to have to intercept it. Some web filters categorise websites based entirely on a big database of addresses, whilst others also analyse the contents of the web pages to improve the accuracy of their categorisation. For the former type of filters, you don't need to intercept; for the latter type, you're losing some of the filtering accuracy if you don't intercept (which may be fine, but you need to be aware of that limitation when you make the decision about what to intercept ). The modern web has a lot of dynamic content that is tailored to the individual users, so there is certainly a good case to be made for analysing what the user is actually seeing, rather than relying entirely on a predefined database of addresses. However, with the old nossl option, anyone could (fairly transparently) intercept your traffic, whereas with SSL interception the user needs to have installed a certificate to allow this. I believe Google's main problem was unscrupulous wifi hotspot providers intercepting traffic, harvesting data, inserting adverts into search results, etc. That's not something that hotspot providers can consider doing if they have to intercept SSL traffic instead. One of the things our customers make a lot of use of is having the filter report on any concerning search terms - picking up on search terms relating to self harm, etc. and being able to have staff intervene is a big deal, and something you couldn't do if you weren't intercepting searches. This is what I've observed from our customers' approaches: - Pretty much all of them do SSL interception on students' devices. Students are usually given instructions on how to sign into the school wifi, which includes instructions on installing the interception certificate. Sometimes ICT staff have to do a bit of hand-holding, but mostly this seems to work ok. - Most do the same for staff, but some have decided that they won't do interception on the staff devices, so no certificate is necessary. - Generally, visitor devices get some light filtering from a transparent proxy, with no SSL interception. So visitors can use the internet without any requirement to install a certificate or change any settings on the device. - Whatever device you're using, some apps simply won't work with interception because they ignore the device's certificate store (this even applies to some of Apple's built in services on iOS devices, which can be quite badly behaved!) and our filters have a predefined list of web addresses that don't get intercepted in order to work around those problems. Every so often someone discovers a new badly behaved app and another address goes on the list and gets automatically pushed out to all the customers. I don't think putting up with constant warnings is really an option - it makes the browser horrible to use, but more importantly would completely break some apps (which would opt to simply not work, rather than popping up a warning). Android devices are a bit of an annoyance for some people, since they put a warning in the notification bar ("the network isn't private" or something like that) all the time when there's an interception certificate installed. You just have to learn to live with that. I'm honestly not sure it's a bad thing either - it's telling the truth, and it does serve to remind people that they should always be careful about what they're doing online. I think mostly this comes down to grouping your users into separate networks appropriately (e.g. staff, students, visitors) and making sensible policy decisions about how much filtering (and therefore how intrusive) each group needs.

Does Sonicwall not do any HTTPS interception? Basically there are two options: 1. Use Google's forcesafesearch DNS bodge to ensure that clients can't disable safe-search. 2. Do HTTPS interception and filter the content as you usually would for HTTP. We have been using both methods by default for about a year and it works pretty well. If you only do (1) then you're relying entirely on Google's safesearch to filter the searches. (2) requires you to install a certificate on each client device, and obviously requires a filter that can do interception.

Funny story - a while ago we had someone propose cutting costs by replacing their leased line with an ADSL *and* moving all their internal servers out to the cloud. They were informed that it was a very bad plan (thankfully they took the advice!)

Sorry!

Sometimes some network ports just don't play nicely with each other - sticking a switch between them means they aren't directly connected together so can avoid some compatibility problems - its definitely worth a go.

Do you think the number of concurrent devices is going to make a significant difference to the amount of bandwidth needed? Is someone with three devices (tablet, phone, workstation) going to use significantly more bandwidth than someone with only one device? They aren't likely to be watching three videos concurrently just because they have three devices.

Usually you'd have a PPP connection to the ISP - the endpoint of the PPP connection is responsible for routing IP traffic to/from the ISP, so it is the default route for your network. The PPP endpoint can be the DSL modem itself - in which case the modem is doing "PPP over ATM" (PPPoA). Or the PPP endpoint could be some other piece of equipment on your network - in which case the modem will be set to be a bridge (which just blindly forwards ethernet packets between the ADSL and the network) and another device will be doing "PPP over Ethernet" (PPPoE). There are other possible configurations, but I'm not aware of any ISP providing them in the UK - for example, Danish ISPs often don't use PPP at all. It looks like that router has two connections configured on it: VCI 38 with PPPoA and VCI 101 is bridged straight to the network (so possibly expecting another device on the network to be a PPPoE endpoint). Might be worth checking with the ISP and VoIP supplier whether both VCIs are correct - I've never seen a setup with multiple VCIs configured so one of them might be redundant. (VCIs are similar to VLANs, allowing multiple separate connections to be sent along a single DSL).

I've seen this a few times and think it's nuts - especially on sites which have a few hundred megabit internet connections who are running their phones over an ADSL! Often it's rigged so that the ADSL provides a nice big security hole that bypasses all the firewalling to the main network too. I suspect it comes down to the phone system suppliers not wanting to get involved with the existing network (I'm afraid I've seen a few phone system installers who simply don't understand IP routing at all - presumably people who were in the phone business long before VoIP happened who still haven't caught up)

You can't do HTTPS interception without distributing a certificate to client devices, so for devices that you can't distribute a certificate to (e.g. visitors) then you would have to accept a reduced level of filtering. But that's pretty much where we stand with all the other HTTPS sites anyway. Even with Google's current solution, you need to set up Google Apps accounts for your visitors, so I'm not sure its any better than my suggestion.