TechMonkey (3rd January 2012)
Background: Planning for a complete overhaul of our network. I'm trying to think of those things that we could implement to future proof the network and make it easier to manage. We have the hardware sorted but my mind is trying to sort out all the other networky bits and you suddenly realise how much you know but aren't actually well acquainted with.
So, we are on a defined IP range from our county grid but I think we could well start to press up against that soon, especially as we are hoping to allow personal wireless devices to start using the network soon. We have a Smoothwall box so my idea is to have that link directly into the router on the county IP range and then all our devices internally on a different range. My thought process would be that NAT can sort this. Am I right and would NAT allow specific County IP addresses to be forwarded to a specific internal IP, for example our internal webserver has requests forwarded to a specific IP from the outside?
Also would setting up VLANs be a good strategy from the start? I think I saw someone post their VLAN plan and it had servers, switches, printers, clients and guest devices all separated. Is this good practice or over kill?
Does anyone run a DMZ? Would this be useful for our webserver (runs website, Moodle and various services) or not much benefit?
Any other thoughts for things to implement?
I have seen the following done in local schools (all of which would seem to answer some of your questions but your area may have its own quirks). My apologies in advance if any egg-sucking is implied for your granny ... the response is a generic response as similar Qs have come up in the past so just taking the chance to answer in a broad way.
A local appliance / box (firewall / filter) runs in between your core switch the LA / ISP provided router / switch. This can either be in routed mode (i.e. provides no NAT but will allow you to keep the ranges as they are) or NAT mode (where there can be many to one or one to one NAT in place). If you are running in routed mode then it effectively runs as you have it right now, but with more control over what is accessed and on what ports. This can come with a performance cost, an administrative cost (i.e. time to configure, monitor, maintain and support) and/or a financial cost. Running it in NAT more allows you to make certain changes but it can be at the cost of existing functionality (more on that later).
If we take a basic appliance first, if you have a range of x external addresses (let us give it an imaginary number of 6 usable IPs ... ) then one is assigned to the device, one is assigned to 'generic traffic' and the others are available for specific NAT rules. The generic traffic means that all traffic from internal devices to the outside world will appear to come from that single assigned IP. This can be a good and bad thing. It can mean that there is something protecting devices from specific attacks int eh outside world but it can also mean that it makes it difficult to track down (from an external point of view) what devices was connecting to things. For example, if the Police com knocking on the door to ask why $IP was trying to access $dodgy_Site ... you then have to track down the internal device using it. You have your own logs on your internal appliance (you do keep logs of course) and then have to track that back to the device depending on how you have your DHCP set up (you do have IP reservations on don't you?) The less serious side of this is when you are trying to work out why a specific external resource is not available to certain devices ... and it can create more work to find out why. These are things to consider when setting it up in the first place and the right documentation / configuration can actually make it a whole heap easier.
You then have that certain external systems do not like NAT. If your upstream filter is party of identity management system which relies on the allocated LA IPs being used on an individual basis then you might find it either no longer works they way you would expect. The answer, usually, is to put your own filter in ... but this then adds to the cost / time / performance mentioned earlier. Instead start thinking about what system may have an issue (talk to other local schools *and* the LA / RBC about this) to try to come up with a range of options. The word compromise is important here ... the school may be using hosted email, access to a VLE and much more which relies on the IdP working. It is not just as simple as putting in your own filters.
Inbound NAT is pretty straight forward ... assign a rule to shove traffic to a specified IP.
The more advanced appliances / systems will allow you to mix and match.
Here you can have a small NAT range for a DMZ, and perhaps even another for your BYOD solution. In one school they have NAT for most student used devices (including classroom machines) and that is run via an internal filter option (DfE accredited and fairly popular in the area) and then staff machines are run out in Routed mode so they pick up the RBC filters, which they also have local control over... and they use the RBC email solution which relies on the regional IdP.
The DMZ has static NATs in place on both sides off access (External and internal) and the BYOD (only just started testing it) looks like it will be managed access with limited external access for the students ... mainly aimed at allowing internal access to Remote Desktop.
Not a complete answer as it doesn't start to cover VLANs but I thought I would cover some of the NAT bit first.
TechMonkey (3rd January 2012)
There are currently 1 users browsing this thread. (0 members and 1 guests)