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: wpa/2 and 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
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
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).
If this page was useful to you, please help others find it:
More Articles by Anthony Lawrence
- Find me on Google+
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.