APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds RSS Feeds











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
->
-> Router down


Router down



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 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.

cartoon

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..

cartoon

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
edit somemachine
 set ip 10.10.1.17
 set mac 00:09:0F:0A:01:BC
 set type regular
end
 

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:  





Comments?




More Articles by - Find me on Google+



Click here to add your comments
- no registration needed!


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar

Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

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.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

pavatar.jpg

This post tagged:

       - Fortinet
       - Networking
       - Routing
       - Troubleshooting















My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide



Buy Kerio from a dealer
who knows tech:
I sell and support

Kerio Connect Mail server, Control, Workspace and Operator licenses and subscription renewals



Click and enter your name and phone number to call me about Kerio® products right now (Flash required)