Wandering Thoughts archives

2016-11-07

Why we have multiple wireless networks around here

I mentioned on Twitter that I wished my iPhone could be set to strongly prefer one configured wireless network over another in situations where more than one was available, to the point where it would switch from a lower-preference network to a higher-preference one. At this point, some of you may ask the obvious and perfectly sensible question of why we even have more than one wireless network available at once.

It is not, as you might first guess, because the various networks run over different wireless access points that were installed at different times by different groups within the university in only somewhat overlapping areas. That certainly used to be the case many years ago for reasons that made sense at the time, but a while back we were able to get out of the WAP business and now all of the various wireless networks involved all run over the same hardware (literally; the enterprise-grade WAPs the university uses handle multiple SSIDs at once). So these days, everywhere that has the departmental wireless network also has the university's wireless network and eduroam.

(The reverse is not true; for various reasons, the departmental wireless network is only available in the campus buildings that we're located in.)

Why keep having a departmental wireless, then? It comes down to network topologies and network access policies. Since we have our own wireless network at a logical network level, we can decide what weird devices can be on it, who does and doesn't get access to it, and how it can have bits of special access to our own internal networks. If researchers or the department has special needs for wireless devices, we can accommodate them. Does someone want to run a wireless robot that simply can't do special authentication and also be able to talk to it from our networks in order to control it? We can accommodate that, complete with holes poked through our wireless NAT firewall if necessary. This is not really possible with the university-wide wireless, or at least not without a lot of discussion and work by a bunch of people. And of course the university wireless can be used by anyone in the university, not just 'only people the department decides to give access to'.

(As a university wide thing, the university wireless group naturally has a tension between trying to accommodate narrow specialized needs for people and running their network in a scalable, manageable way, which in part means 'as few special cases as possible'. We run a much smaller network for a much smaller population, so we can afford more special cases and weirdness than they can and we don't need to be as scalable as they do. The overall university wireless usage is apparently scarily large; I've heard jaw-dropping numbers for how many concurrent active devices there are during peak times.)

As a wireless user in this environment, you have a relatively clear preference order for wireless networks but also a reason to have all three configured. If you're in campus buildings with the departmental wireless available, it's best to use that. If you're elsewhere on campus, you'll obviously want to use the general university wireless. And if you're off at another institution, you'll want to use eduroam to get more or less campus access (including access to resources that are restricted to University of Toronto people, such as certain online library resources and journals).

(I don't know if we'd still build a departmental wireless network if we were starting over from complete scratch today. There's some arguments for it, but our current wireless situation clearly benefited from inheriting a lot of existing firewalls, configuration, and so on from our old completely independent wireless network, and there are aspects of our departmental wireless network that we deliberately dropped support for when the university wireless became pervasive.)

sysadmin/WhyMultipleWirelessNetworks written at 22:25:31; Add Comment

The other reason why I've wound up not interested in firewall managers

In a comment on my previous entry on not using firewall managers, Durval Menezes mentioned:

The real problem IMHO with "magical" solutions is when the "magic" suddenly stops working (specially when it falls in some subtle, hard to detect way) and, as it made it "easy" to start with, you have no control nor/nand internal knowledge of it to troubleshoot (or worse, even detect that it has failed in the first place).

Now that it's been brought up, I have to admit that this is a good part of what's quietly influenced my thinking too. On Linux, firewall management systems like FireHOL and Shorewall aren't self-contained systems; instead they're all eventually using iptables (or someday nftables), possibly plus routing things (including policy based routing for some of them).

I'm a sysadmin. I know that someday the magic is going to fail and I'm going to have to go down in the guts of the actual generated iptables rules and so on to figure out just why things aren't working. If I'm going to eventually need to understand the iptables rules, well, there is certainly a part of me that feels I might as well cut to the chase and understand them from the start. The other issue is that I expect automatically generated rules to be harder to understand than hand-written ones, because a decent rules generator ought to be able to pull off any number of optimization tricks that no sensible human would use when hand-writing rules (and these optimizations are undoubtedly great when things work well).

As a side note, what this suggests is that (Linux) firewall managers should ideally come with debugging tools, much like compilers for languages generally have them. In both cases you wind up with symptoms in low level things (your program crashes, your firewall doesn't seem to be working right) and you want to go from the low level bits back to the high level source and concepts involved at the time. Imagine the use of being able to find out 'this connection was blocked because of this high level rule you set'.

(Of course I don't know if Linux's networking stack is set up so it's even possible to trace packet firewall decisions in the way you'd really want in order to do this. I think there's some new logging stuff, but I haven't looked into it since my last attempt failed. I should, though; being able to log and/or trace firewall activity is important no matter how I wind up creating my firewall rules.)

linux/FirewallManagersAddedComplexity written at 00:04:46; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.