Router Down: Some Days You Just Can't Win
Some days you just can't win. One of my clients (you know who you are) had such a day yesterday.
It started with doing some reprogramming of a Fortinet WiFi router. Normally I don't like to see WiFi in a business environment, and if it must be there, I like to see it locked down very securely: access by pre-approved MAC address only if possible, and if not, limited to very little access - maybe just Internet for the convenience of visitors but darn little else. But that's me: some businesses have reasons for allowing more, and that was the case here.
So it started with "How am I going to let the wireless side be able to browse the internal network?". The answer, of course, is to point that side's DNS at whatever server knows about internal machines; in this case that would be their Windows Domain Controller. I wanted the Wireless DHCP to provide the router itself as the secondary and the Domain Controller as the primary, as shown in this screen shot. The router's internal ip is 192.168.2.250, the DC is at 192.168.2.49, and the Wireless itself is on 10.10.50.1 and will be handing out addresses from 10.10.50.2 through .20
If you are used to home appliance routers, you may be confused right now, because most of these will set things up so that the wireless and wired are on the same subnet. That's not how we do things in the big-boy world: Wireless and Wired will be separate subnets. That's so that you can create appropriate rules (policies) to control access to your business computers. Sure, Mr. Traveling Salesman doesn't have the password to your main server, but why should he even get a chance to see it, never mind try to log in? He shouldn't. So there will be more work to do on the policies: only trusted machines should be able to get to the internal network. But I digress..
So, initially I had set the wireless side to only get DNS from the ISP. The ISP of course knows nothing about internal machines, so that had to be changed. My client went into the Fortinet browser config to do that and..
Probably because he's also in charge of two hundred other things - he's the kind of guy who always has other people asking him questions when you are on the phone with him - "What do we do about.." and he'll say excuse me, and then you'll hear him bark out a string of instructions before he returns to your conversation - probably because he gets hammered from six directions all day long, well, he made a teeny little mistake. Instead of changing the DNS to point at his Domain Controller, he changed the Fortinet's internal IP to that address.
Oh-oh. That's not good. IP conflict with the main server. Definitely not what you want. But it should be simple enough to fix.. right?
Well sure. Just isolate the Fortinet and one computer from the rest of the network and there's no IP conflict. Reprogram it, put it back, and we're all set. Simple, right?
Um, apparently not. By this time he had called me, so I led him through the rewiring (or unwiring), and we programmed his PC manually (because he had, of course, shut off the DHCP server on the Fortinet), but it wouldn't connect. No access. Ugggh. Maybe he fat-fingered some other address in? We tried a few possibilities, but no luck..
So, time to dig out the serial cable. Unlike many home routers, Fortinets do not have a little button you can hold to reset to factory defaults. You need to get logged in to do that: Hyperterminal, 9600, 8N1 and (important) Software (Xon/Xoff) flow control. Login , and let's repair the damage..
Except, darn it, I can't remember the right command to reset just the IP. So what command shows me what it is now? I know it's "show something", but I could not remember what. Later on when I found the manual I realized that just "show" by itself would have given me what I needed, but (as you might expect) the client didn't want to wait around for me to look it up. "So let's just reset the whole thing and re-enter it." OK, why not? I know there are backups of the config on one of the servers, so that will actually be easier. So: "execute factoryreset". Done.
Program the PC to 192.168.1.1 (the Fortinet is 192.168.1.99 when defaulted) or just set it to DHCP.. reconnect through the browser and program it to its correct address. Reconnect to the network and we'll restore the backups..
But nothing is working. Why? Well, apparently (probably again distracted by someone with a problem), he forgot to hit "Apply".. so he thought he had changed the address, but had not.. reconnecting by serial showed that plainly, and by this time I had found the CLI manual so I gave him the commands to reset his IP right there:
So now most everything was right.. he couldn't find the backups I had made originally, but it didn't take long to go through the configuration and get everything working.. except..
Something was wrong with some machines. Most of his network was now working, but parts were not.. I had him do an "ipconfig" on one of those and was surprised to hear that it had a 192.168.1.57 address.. surprised because the network is 192.168.2.255. Where on earth could these machines be getting that 192.168.1 address from? Was the Fortinet actually connected to the network when we had reset it?
No. Actually, this was pretty much the same situation as I described at Routers and switches and hubs, oh my!: somebody had plugged in in an old router where they needed a switch. Amusingly enough, this was one of the semi-tech guys who should have known better (certainly does know better now).
So, after several frustrating hours, all was once again well. I made sure that the Fortinet's configuration was saved on multiple machines so we don't have to go through this again.
By the way, probably the easiest way to control wireless traffic is to force known MAC addresses to specific addresses. That can't be done through the browser, but can be done at the command line:
config system dhcp reserved-address
set ip 10.10.1.17
set mac 00:09:0F:0A:01:BC
set type regular
The "somemachine" is just a name you give for this, the rest should be obvious. With this done, you can write specific ip based rules for those machines, and lock the itinerant salespeople out (while still giving them the convenience of Internet access for their demos).
*Originally published at APLawrence.com
View All Articles by A.P. Lawrence
Our Daily Email of Breaking eBusiness News
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
WebProNews RSS Feed
More Expert Articles Articles