Unix and Linux Help, Resources and information for Unix/Linux, Mac OS X. Articles on blogging, web site mechanics, and self employment. Mostly techy, Unix/Linux related, but we don't really try to stay tightly focused. If you've never been here before, there's a lot to explore.
One of my long term customers called me with a complaint about his daughter. No, I don't do family counseling; this was about a company wide email message that was being duplicated over and over again. When he called me, he already had several hundred copies of the email she had sent and so did every other person in the company.
Duplicate email usually has a simple cause: the sending end never got an acknowledgement from the server that the message was received intact, so, assuming the worse, it sends it again. If, however, the receiving server thinks that it got everything and that it did send an acknowledgement, it will get busy passing that message on to the recipients. When the next message comes, it happily passes that on too.
You wouldn't expect this to keep happening. Sure, something might go awry once or twice every now and then, but not hundreds of times.
We do often put some limits on this dance. For example, we'd usually set a hard limit on the number of messages per hour from one IP address. This will at least slow down errors like this.
The cause of this could be faulty software or a bad network connection. I'd look to the sending machine's network card or cable as the cause, but even that would be very strange: it's hard to be defective so that the acknowledgement is missed without being so defective that nothing works at all.
If this were happening to multiple people, I'd look to an SMTP protocol inspector at the firewall messing this up. In my experience, that particular interference would be with large attachments, not small text message as this one was. Also, that usually wouldn't repeat more than a few times.
In this case, her father knew that she was out of the office and therefore had to be using her cell phone. I therefore suggested the quick solution: nuke the email account on her phone.
That's not as draconian as it sounds. All data is stored on the server; the phone account can be set up again in less than a minute. Killing the account will quickly stop any sending and if it didn't, killing the account and shutting the phone off surely would. So that's what we did and of course the duplicate emails stopped.
It's not hard to find accounts of others having similar problems. Those referenced Exchange servers, but ActiveSync is the common factor. It could be the phone software, but it could also be the network connection - perhaps she was in a bad reception area when she sent the message - though, again, it's hard to imagine why the message would get sent and only the final part of the communication get screwed up.
Anyway, problem fixed with nothing more than a quick phone call. I thought we had put that behind us, although she would have to test her phone and be sure it was not faulty software.
Two weeks later, Dad called again. This time he told me that his daughter couldn't access her email. I asked if he meant from her phone; no, she had not even restored her account yet. She was unable to see mail on her desktop not twenty feet from the server room.
We felt that warranted a hands-on visit. I could have VPN'd in, but they are not that far away and I had some shopping to do along the route anyway, so I headed on over.
When I arrived, I was momentarily puzzled. Looking at her mail directory in the Kerio Connect store directory, I could see that it contained well over 200,000 files. However, her Inbox, Sent Items and Deleted Items were all small - less than 200 messages in any of them. The largest email folder in her directory had 7,500 messages and the total of everything was less than 10,000. So where were all these files?
I found them in Calendar - over 200,000 entries.
Of course calendaring is a separate part of Active Sync - nuking the email account wouldn't affect that, and apparently this phone was having the same trouble with Calendar events as it had with email - it had been sending them repeatedly for two weeks and that finally broke her mail client.
I deleted these from the command line, and then told the system to reindex her mailboxes. The deletion and the reindexing took about 30 minutes but she was able to get in after that.
Although Kerio recommends shutting down the server in these cases, I didn't. I had her close her email client and shut off her phone; there was no danger of calendar events arriving from anywhere else so I saw no need to inconvenience the rest of the company. Still, recommended practice is to bring the server down.
I told her she could try reactivating her account if it was OK with her father and told him that if he did that, he should watch her mailbox closely for a few days just in case. We need to find out if her phone is broken or this was just a transient glitch. My suspicion is the phone because of the calendar entries building up over time. It doesn't seem to be transient, and the similar circumstances I can find in Google indicate that something is broken in the phone software. If she reactivates her email and that starts acting up immediately, that would seem to nail it, although I'm not sure what she'd do at that point: I didn't find any definite solution in my Google searches.
/Kerio/kerio_android_message_delivery.html copyright and reprint notice
I'm a small business, Basically, the business is me and at one time I did it all: prospecting, sales, tech support, billing and accounts receivable. Of course I also did the filing, though I confess that with the crush of everything else, that often consisted of just laying the latest piece of paper on the top of a pile of older things.
When my wife stopped working, she took pity and began handling the paperwork side: billing, making up deposits, chasing slow payers and of course the neglected filing. That took quite a burden off my shoulders, but it also partially disconnected me from my customers. I no longer had involvement in the accounting side, so I lost part of my knowledge base.
Of course I could get at that information: I've used Quickbooks to handle all that for years and my wife just continued that. I could call up any report or customer detail at any time, but that's not quite the same as actually doing the work.
Although I do a fair amount of simple selling, both product and support, most of my business is built around recurring subscriptions - support and licenses. Tracking those subscriptions can be difficult, especially when it involves other companies as it does with software licenses. Quickbooks doesn't help me with that, so long ago I wrote scripts that alert us to expiring subscriptions. Those are useful, but I needed more. What I really wanted was an electronic filing cabinet where I could put everything I need or want to know about customers.
That part by itself wouldn't have been too hard to do, but I also needed something multiuser that would be easy for my wide to use and understand.
Kerio Workspace gave me exactly what I need. Its ability to merge in text notes, pictures and any type of file gives me a full record of all customer interaction. Of course I can keep track of upcoming renewals, keep notes on contact name and email changes, but I can also attach copies of invoices, scripts I wrote and records of support incidents and resolutions. The automatic tracking of file versions makes that ability particularly powerful for scripts and invoice history.
Now EVERYTHING I know about my customers can be in one place. The search capability lets me quickly find whatever I need and the ease of use lets my wife update those parts that are related to invoicing and collections.The granular sharing controls lets me only show her those parts of the records that she cares about, so her view can be much more compact than mine.
This layout can give me everything I want, but if I could interface it with my scripts using an API such as Kerio has provided for Connect, I could automate even more of it and actually make it rival commercial CRM software. The ability to automatically copy renewal information to the man customer space would make this much more like a real database and eliminate manual work. I hope that is something Kerio will consider in the future.
/Kerio/kerio_workspace_crm.html copyright and reprint notice
I'm very happy today. Yesterday I installed a brand new Kerio Control box at a customer I've known for almost 20 years now. We replaced an Astaro firewall that had been put in just two years ago and you probably think I'm happy because I made a sale, but no, that's not it at all.
I'm happy because my customer is now going to get decent support.
With the Astaro, he was getting awful support and at a damn high price, too. His phone calls and emails would often go ignored for days and sometimes weeks. There was nothing wrong with the Astaro itself and I suppose he could have gone searching for some better Astaro reseller to take over the support, but instead he and I decided to rip and replace - he'll be paying far less in the long run and I do NOT ignore my customers! That's why I'm happy.
My plan was to replace the Astaro with Kerio Control on Wednesday. We knew the Astaro license would expire a few days before that, but I only got the unit the previous Wednesday, and of course I had other things on my schedule already. I expected that Astaro would have some reasonable policy on expired licenses. For example, Kerio Control has this policy:
If the License (or the trial period) expires, the functionality of the product will be limited. In particular, the following features will be turned off:
* IPS, integrated and external anti-virus engines
* VPN Server, all tunnels, SSL-VPN Server
* Accounting - gathering statistics,
* HTTP Policy, FTP Policy, HTTP Proxy Server, Forbidden words
* Bandwidth Limiter, is turned off
* 'Require user authentication', NTLM authentication
* UPnP server, P2P Eliminator, Anti-spoofing, MAC Filter
* Kerio Web Filter will stop working
I expected Astaro to have something similar.
On Saturday afternoon, however, someone from the customer called saying that the Internet was down. I wasn't where I could test anything at that particular moment, so I asked them to call their ISP (Verizon) to see what they said. An hour later the customer called back, telling me that Verizon said a line was "down" somewhere.
I shrugged my shoulders - there's not much I can do about that, although I knew that they also have a slower line and I thought that would have been configured for failover. The person I was talking to on Saturday would know nothing about that, though, so perhaps they had simply discontinued it.
On Monday morning, I had a call from my usual contact. Apparently Verizon had not yet fixed the problem. They were 'on their way', he said and had narrowed it down to something very close to the building. I commiserated, but then he said something odd.
"Email is still coming in. I can't send email, but I get it."
Excuse me? If the Verizon line is down, how could anything be coming in? Unless maybe it was coming through the failover line? But why wouldn't he be able to get out? I was at a computer now, so I ssh'ed to his Linux server and, sure enough, it let me in. But once in, I couldn't even ping outside sites. That made no sense to me and I suspected the Astaro licensing. I asked him to check what the Astaro said about its interfaces, but he couldn't see much: almost everything he looked at just said his license was expired.
I offered to reschedule and come in early Tuesday, but if Verizon was still looking for a broken line, that didn't seem to make sense. We decided to leave it for Wednesday.
Of course I preconfigured most of this before going on site, but I didn't add users or fully configure the secondary Internet line - it might not exist. When I arrived, Verizon had just completed the repairs and had asked him to reboot his routers. Good timing!
We headed down to the network closet and I found pretty much what I expected to find. The Astaro had three CAT5 cables plugged in. That would be one for the main ISP, one for the failover and one for the network switch. I pulled them out and started hooking up the new Kerio Control..
All hell broke lose a few minutes later. Cries of pain echoed down the halls. I had somehow disconnected them from their server!
That made no sense, but then we looked more closely at the line coming from the "failover" connection. It was disconnected and had been before we walked in. Huh?
"Oh yeah - I remember he [the Astaro guy] had me disconnect this. It was slowing us down.", my contact guy explained.
Slowing you down? "Wasn't it a failover?", I asked. No, he explained: it had been configured to use both, but it is a much slower link, so people were complaining..
I muttered something unfriendly about the Astaro guy. That link shouldn't have been configured for load balancing. If you have a fast link and a slow link, you either configure the slow one for failover only or you use it only for some specific purpose like incoming mail - you don't plague users with it! I pulled out the "wrong" wire and plugged this one in to the port I had planned for failover.
But what about the wire I just pulled out of that port? What the heck was that? How could we have two connections to the network? It took me a few minutes to understand: there were not two connections to a switch; there was a connection to one switch and a connection to another and the firewall was sitting in the middle! So of course I killed the network when I switched it - I plugged half of their network into a port I had configured for the failover link! The really hilarious part of it was that a little 8 port switch was sitting right there - that extra line could have been plugged into that instead! Sheesh!
But at least we were working. Within a few tens of seconds, people had Internet access again and the network was reunited. I began introducing my contact to his new firewall.
I like to set up the VPN users and administrators first. Those are the users we absolutely need to define; the rest can wait. We already had six or seven people who ssh in and I had defined a DNAT rule to bring them in, but I explained that it really would be better for them to use the free Kerio VPN client instead. That would give them access to all network resources instead of just logging in by ssh. We set them up and gave them VPN rights.
I held off on adding any more users because I wanted to show him a neat way to do it in Kerio Control. This way is easier for everyone..
In the DHCP section of the firewall, you can see leases. If you double click on one, you can give it a name (helpful when the machine names were carelessly assigned) and reserve the lease so that the device will always get that same IP. Why do we care? Because in the user config, there is the ability to assign an IP to a user - when the system sees traffic from that IP, it logs it as belonging to that user.
In this case, that "user" is called "Front Desk Downstairs". Note that spaces in the name are fine and that we really aren't defining a user - we're defining a machine. The Kerio reporting will treat it as a user and a user with more rights could specifically login at that machine, but otherwise we don't care who uses it - we're tracking what happens at that machine. The real user doesn't have to login, doesn't have to know the assigned password, really doesn't have to care at all. But the administrator can now easily see that "Front Desk Machine" spent a lot of time on Facebook just before lunch..
That's a simple and transparent way to handle users. The only people who even need to know passwords are the VPN users or anyone who has rights to unlock otherwise protected content. The administrator gets the oversight and the users don't have to login.
Kerio Control has a built in rule for its Kerio Web Filter, but don't forget that you have to double-click on it and select the specific categories you want to block.
Of course there may also be things you want to block specifically. The easiest way to do that is to create a new URL group:
And then add an http policy that blocks them:
This doesn't clutter your policy with dozens of rules and makes it easy for the administrator to add and remove sites.
Kerio's StaR reports seemed to really fascinate my contact. "Didn't the Astaro do something like this?", I asked. He replied that it did, but only by IP address, so he never knew who was doing what. He said that the Astaro guy was "supposed to fix that", but never did.
Yeah. I think can you see why I was happy about this sale.
/Kerio/kerio_rip.html copyright and reprint notice
There's a bit of a storm brewing at the Kerio user community forums over Kerio's recent announcement that they intend to charge for support in some circumstances. Some of this is just simple misunderstanding, but other users feel angry and perhaps betrayed by this sudden change in policy.
Because it's important, I'm going to restate two things that some people have ignored:
Pre-sales and registered Trial support will be free. Complimentary Installation Period Support will also be available for 90 days after the registration of a purchased licence.
Any support incident that results in a bug report or an RMA, or is a known Kerio product bug, will of course not be charged for.
I'm also going to be very honest here: I think Kerio handled this badly and that there were other options that might have eliminated the need for this upsetting change. On the other hand, I support the change if it will encourage customers to contact their resellers for support rather than Kerio.
I have more than one reason for my support. One of my reasons is actually greedy and selfish: Kerio has more than a few "bad" resellers who do NOT support their customers well and I'd like to take over those accounts who become disenchanted with their poor support. That's the self-centered reason that I support this change, but there are more reasons.
Good resellers can often do a better job at support than Kerio can. There are obvious exceptions, of course: if we are talking about a bug, the reseller does not have access to the resources Kerio support has access to. We don't get to see source code and few of us can maintain every possible supported equipment configuration to test scenarios.
On the other hand, those are not what most support calls are about. If you read through all the troubleshooting articles I have written here over the years (all of which were taken from actual support requests), very few involve product bugs per se. More usually, these are "fog of war" problems, confusing problems brought on by unusual conditions that aren't always easy to see. As a support person, the more knowledge you have of the customers environment and of the customer personnel, the more likely you are to solve the problem quickly.
This requires a relationship with the customer. It requires knowing what they do, what hardware and software they use, what their technical expertise is and what their past history has been. A reseller may have that relationship and that knowledge; Kerio support personnel may not.
Don't forget that the reseller always has the option to bring Kerio support into the conversation. Kerio resellers are NOT charged for support, so the reseller can augment their own knowledge with Kerio's.
The reseller may also be capable of doing things that Kerio support cannot. For example, I've helped many customers with network problems, virus problems and hardware issues. Kerio support can't reasonably offer much help once the problem is plainly not their software, but the reseller may very well be able to chase the problem much farther.
The scenario many envision is this: The customer sends a problem to the reseller. The reseller passes it to Kerio. Kerio answers the reseller requesting more information, the reseller in turn asks the customer and on we go.
That may very well be what the "bad" resellers do, but it's not what I do. If we're exploring a problem by email, I cc the customer when I initiate the support ticket with Kerio and ask them to cc the customer in turn when they answer. If we are doing this by phone, I'll call Kerio and then conference in the customer. This avoids all the delays - everyone is on the same page at the same time.
That's assuming I even need to contact Kerio. In the almost eight years I have been selling Kerio products, I have had very few conversations with support. I handle most calls myself, because most calls are not bugs and are not difficult.
Well, that's obvious: having resellers handle tier one support reduces their costs. But there is more to it. Kerio has reasons for having a reseller network and a very important part of that is the relationships resellers have with their mutual customers. Those relationships usually mean longer term opportunities for Kerio.
I may be odd, but I don't look at the support I provide as an expense. I see it as opportunity. My motto for many years is that there are no problems, because every problem is always an income opportunity for someone. The opportunity may be obvious or it may be subtle, but solving problems often leads to more sales, now or in the future. Even when it does not directly lead to new business, good support helps ensure business retention, something that every good reseller knows is vitally important. Therefore, those "bad" resellers who look at support as annoyance and are anxious to pass it on to someone else are really missing out. Sooner or later they will lose their customers to someone like me who is willing to give good service and support.
There are things I don't like about this. For example, I don't want my customers going to Kerio for that 90 day "free support" period. For all the reasons detailed above, I want them running those questions through me.
I'd also prefer that Kerio support be able to conference call me and my customer when we've opened a ticket that requires that. That's a minor issue, of course. I'd love it if we could do Google Hangouts with Kerio support and my customer when needed. That could be a very good way to handle conferences and even written communications.
I also feel that Kerio has not yet done enough for the reseller's needs. We need access to bug reports and we should get immediate notification if one of our customers has contacted Kerio directly - we should get copies of all conversations and solutions, both so that we can follow up if more help is needed and so that we can be aware of issues that may affect other customers.
We should get better technical training. Kerio does provide some training, but it hasn't been in depth. I'm sure they must provide better to their in-house people; resellers need access to similar resources. That may not be easy to do - there can be confidentiality issues, of course, but we should at least get masked reports (expunged of customer information) of current support requests and their resolutions. That would help us support other customers better.
Kerio also needs to manage their reseller channel better and make partners more aware of their obligation to provide customer support. I suspect most have been accustomed to just telling customers to "call Kerio" - that needs to stop.
If a customer does call Kerio direct, I'd like to see support strongly encourage them to call their reseller instead - perhaps even offering to try to patch the reseller in right then and there, or in the case of a written ticket, cc'ing the reseller with the initial response.
Support is important. As I said above, it is important for all three parties involved. I see posts at the forum that strongly imply that some see the reseller as a rather useless cog in this particular wheel, but that's not my view at all.
/Kerio/support_policies.html copyright and reprint notice
A New York customer had recently purchased another company, so they added that company's email domain to their Kerio Connect mail server. A few users were moved in one direction or another and everything seemed to be going well.
As the newly purchased company needed some hardware upgrades, new Windows 7 machines were purchased for several of their users. That's where the trouble started..
The new machines could not seem to synchronize with Kerio.
For those who aren't familiar with Kerio, let me explain that in addition to Webmail, POP3 and IMAP, Kerio supports a MAPI configuration which gives Outlook most of the important features it would have using Microsoft Exchange. This requires the installation of a Kerio Outlook Connector (KOC) on client machines. After installation, the KOC attempts to bring down message headers from the server - synchronizing its view of email with the servers. It was this process that was failing.
IMAP has a similar synchronization and both it and Webmail performed badly on these new machines also, although not quite so poorly as the KOC did.
The situation was described by Rick, their IT guy, to me over the phone and then he followed up with this email (I added comments and explanations in [brackets]):
Given: Both users are at[the new company], and work fine on Windows
XP with Office 2003 SP3 with the Outlook connector
Both users have Windows 7 Pro, and Office 2010.
I have Windows 7 Pro with Office 2010 with -0- problems
The ONLY thing I can think of is the Domain. I have no domain.
So, I asked [tech person at the new company] to set up a new machine,
but don't join the domain.. Then try the KOC setup. NO PROBLEMS!
Then she joined the machine to the domain, (and had to setup
KOC again, because it's a new profile on the computer.) and
BAM! PROBLEM setting up KOC!
Let's pause for a moment, shall we?
This HAS to be a domain policy. Rick said so himself here and I said the same thing.
One small wrinkle, though: the old XP machines are in the domain and they worked fine. Moreover, everyone at the new company swore up and down that there were no policies applied - the domain really was only to help protect a few shared resources from unauthorized users
So, we bumped it up to Kerio Support. They looked at logs and didn't have much to add:
Thank you for the log information. It appears as if there is network connectivity issues as soon as you join the domain. the debug log shows it unable to locate items (404 not found errros) and RPC server unavailable. Something is blocking these machines as soon as they join the domain. Can you check the windows event viewer for any sign here of issues? other warning messages. What Antivirus is used on these machines. Are these the only win7 platforms on the domain that are having this issue? are there win7's that are working? I have to be honest, that I have not seen this type of issue with domain based win7 boxes, since we use them ourselves and many other clients/customers are running win7 without this type of issue. It has to be something about this domain that is causing the issue.
So, really, it HAS to be the domain, right?
Microsoft was summoned. At first, they thought it was Outlook. Then of course, they suspected Kerio, but had to agree that Kerio worked correctly before the machines joined the domain. Rick also showed them that Zimbra IMAP had the same problems Kerio exhibited.
Meanwhile, Kerio second tier support confirmed what we thought we were seeing:
The development team writes that requests from KOFF to Connect are timeouting when downloading partially synchronized message.
I wondered about the Internet link at the new company. It's only a T1; were we overloading it? But that made no sense because, again, the trouble only showed up when the machines joined the domain and that sent me back to domain policy and there was none.
Meanwhile, Microsoft had decided that this was indeed a domain related network issue and bumped the case upward in their support chain. A week later, they fixed it.
As we all said, this had to be a domain policy, and Microsoft pointed at "Remote Installation Services". There are four options in that policy:
Each option can be set to Enabled, Disabled and Not Configured. In the murky past, someone had set Custom, Restart, and Tools to "Disabled". Microsoft had Rick set them back to "Not Configured".
I have to bring this train to a screeching halt for just a minute. This Remote Installation Services is for installing OS images on PXE capable systems. Therefore, unless you actually are installing operating systems, it would seem reasonable to assume that the most this service would be doing is listening for BOOTP requests - and it would only do that if it were enabled. Moreover, given Microsoft's explanation of "Not Configured" (see image below), that is no different from "Disabled" in this case.
However, Microsoft code is full of strange things. While being prevented from listening for BOOTP packets, perhaps the PDC gets bored and decides to echo random thoughts back out on the wire, interfering with our synchronization?
Perhaps Windows 7, feeling humiliated by the looming shadow of Win 8, desires an OS transplant, and, noticing that this option is specifically disabled, cries out in pain, throws itself on the floor and trashes around in tantrum? Whatever: if Microsoft tells you to change a setting, you change the setting - even if they admit they have no idea why it matters.
Microsoft also had Rick do this:
We had to issue the following commands at the command prompt (AS ADMINISTRATOR!) [on the Win 7 machines] netsh interface tcp set global rss=disabled netsh interface tcp set global autotuninglevel=disabled netsh int ip set global taskoffload=disabled netsh interface tcp set global chimney=disabled When complete, the command : netsh int tcp show global should show everything disabled except for NetDMA State
That makes more sense. This has to do with smarty-pants NIC cards that can take on TCP/IP processing that the OS would normally handle. If you google for "Win 7 SNP", you'll find articles that recommend similar actions for similar problems. Interestingly, this stuff goes back to Server 2003 - I found this "update to turn off default SNP features", which leads off with an explanation of all the bad networking trouble this can cause:
This makes sense - apparently Microsoft coders and the NIC card coders aren't communicating well and the result can be a mess like this. I can't imagine how this has anything to do with Remote Installation Services, but so what?
But why does it turn up only after joining the domain? Does the domain change the Win 7 TCP/IP stack? Darned if I know.. I did some Googling but couldn't zero in on anything helpful. Apparently something happens - because Rick reports success:
And this my friends provides us with a Windows 7 computer on a Server 2003 Domain that operates quickly, smoothly and most enjoyably.
Rick explained in a phone conversation that they tried doing just the SNP, but without changing the domain policy, it did not help. We all agree (even Microsoft, apparently) that it makes no sense - when KOC is talking to the mail server, the DC isn't even involved, but there it is just the same: both these actions were needed to fix the problem.
So, two weeks after the initial problem, and with much wailing and gnashing of teeth, the problem is solved. Happy workers are now reading email on their brand spanking new Windows 7 machines. I'm sure Rick is sleeping better and those of us who work in the field should remember this SNP stuff for future reference.
If this had been happening BEFORE joining the domain, the first thing I would have tried is adding a different NIC. That's a simple and quick test for driver weirdness, but because the silly things worked outside of the domain, that thought never entered my head. It's good to keep in mind that for this kind of troubleshooting, you actually want a no frills, basic, simple NIC that Windows has known how to handle for years - no smarty pants hardware need apply. Had I been wise enough to do that, the finger would likely have pointed at the NICS instantly and we either would have got to this point faster or would have just bought a box of new NICS and gone around the problem. But I did not.
But that's life, isn't it? We get led astray at times and it can be hard to resist that. Had I suggested trying different NICs, I probably would have met resistance because it worked until they joined the domain. So, maybe it doesn't matter, but I wish I had tried just the same.
/Kerio/koc_domain.html copyright and reprint notice
Kerio Control has been available as a hardware appliance for some time now, but I hadn't actually directly worked on one until this week when I had two of them to pre-configure for customers. Both of these were the smaller model, the 1110 series.
I had never paid close attention to the physical specs, so the size of these surprised me a little when I took the first one out of its shipping box. I thought the unit was attractive (hardly important for a firewall, of course) and put it down on my kitchen counter for a snapshot.
As you can see here, this has a four port switch. For initial configuration, port 1 is assigned to the Internet connection and the rest are for the LAN. This can all be changed later, but for initial setup, that's what's expected.
The power switch is over to the right as indicated above. When you first plug in the box, a red LED in that switch turns on, indicating that power is applied but the firewall is not running.
Pushing the switch in powers up the firewall and the switch LED turns blue.
Did you notice the USB ports? They are for Kerio's USB tools, which can be used for forgotten admin passwords, total factory reset, failed upgrades and diagnostics. Normal upgrades are done through the web admin (update check failed here because I'm not connected to the Internet):
The serial port gives access to the Linux console (though I don't own anything that still has serial ports - I'd need to use a USB to serial adaptor).
I plugged my iMac into port 4 and let it get the default 10.10.10.x IP address and pointed my browser at https://10.10.10.1:4081/admin as the instructions direct. This brought up the initial configuration dialog.
I thought I might have to temporarily let this box have my Internet connection to complete the installation as some of the prompts implied that configuration would continue only after connecting to Kerio, but in fact I was able to do everything with no working Internet at the box. I used my own connection to register and download the license file and installed that through the LAN connection to the box.
Configuration is basically no different than in the software versions of Control, so I quickly had everything set as I wanted it. I was pleasantly surprised to see this warning pop up:
That's a nice feature for those of us who fat-finger things every now and then. I hadn't painted myself into a corner this time, though, so was able to get logged back in with the new LAN IP. I also added an alias for an IP on my network so that I could do more configuration without my iMac being disconnected from the rest of my network.
Further configuration was routine. I added the users who will have VPN access, added a few known internal hosts to the DNS file and configured a DHCP scope to match his existing firewall. I disabled the DHCP temporarily so that the customer can plug this in to his network to become familiar with it and make any last minute changes before replacing the existing firewall.
I also enabled ssh (hold SHIFT while clicking on Tasks in System Health) just to take a look at the internals:
Poking around a bit showed nothing unusual or unexpected:
~ # df -k Filesystem 1K-blocks Used Available Use% Mounted on rootfs 497581 299785 172796 64% / /dev/sda2 497581 299785 172796 64% / tmp 1033372 176 1033196 1% /tmp dev 2048 496 1552 25% /dev /dev/sda1 24395 12714 10461 55% /boot /dev/sda4 2893096 122120 2624012 5% /var ~ # cat /etc/inittab # $Revision: 1.1 $ ::sysinit:/usr/bin/run-parts2 -a start /etc/boxinit.d ::ctrlaltdel:/sbin/reboot ::shutdown:/usr/bin/run-parts2 -r -a stop /etc/boxinit.d ::restart:/sbin/init tty1::respawn:/usr/sbin/kerio-console.init tty2::respawn:/sbin/getty -L 9600 tty2 tty3::respawn:/sbin/getty -L 9600 tty3 ttyS0::respawn:/sbin/getty -L 9600 ttyS0 ~ # ls /etc/boxinit.d 00udev 06network-base 15kipf 21postinst 59consoleApp 01kernel 07syslogd 18acpid 30custom 60winroute 05basefs 09usbscript 19parallels-tools 31ssh 97setdefaultboot 05hwclock 10console 19vmware 40firebird 05sysctl 11factoryreset 20network 50winbind ~ # lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 04) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) 01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 04:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
Notice that each ethernet port has its own card? The default is that ports 2-4 are your LAN, but that can be changed:
The box is ready to go. I'll talk to the customer today to see if there is anything else he wants done before I pack it up to ship to him. He'll need to add any other users and machines he wants to track and we'll double check the rules once it is attached to his network, but it's basically ready to plug and play.
/Kerio/kerio_hardware_firewall.html copyright and reprint notice
Comments /Kerio/kerio_android_message_delivery.html
Add your comments