At Adding a new mail domain with Kerio Connect I mentioned how a Kerio customer planned to integrate a new mail domain into their existing system. That all took place this past weekend and everything was working fine until someone tried to use a network capable scanner. That was set up so that scanned documents would be emailed to the user, but the mail wasn't working.
Of course I asked the most obvious question first: had they reprogrammed the scanner with the new (Kerio) SMTP server information. Yes, they had.
Led astray by what we think we know
Right here is where things went bad for a few hours. I hasten to add that fixing this would have been quicker had I not been out getting a haircut and running a few errands. None of this should have taken hours. However, it's a good lesson in the power of assumption.
Let's start with what I knew. I knew that we could telnet to port 25 from a machine on "New Company" to the Kerio mail server. I knew that because I had led their tech guy through a whole SMTP client impersonation drill last week.
I also knew that the Kerio server was set to require authentication for non-local clients, so I knew what needed to be done to fix the scanner: either have the scanner authenticate or set Kerio to consider New Company's IP as part of the local IP group. Either method will work. Could the scanner use authenticated SMTP? No, it could not, so we'd have to add the IP to the local IP group. Easy fix. I told him what to do.
However, that's when the curve ball came.
"I can't get out from 'New Company' on port 25 at all", their tech guy informed me.
Well, strictly speaking not exactly "their" tech guy. This guy was OLD Company's tech guy, so we can forgive him for not being entirely intimate with New Company's network just yet. Either way, as I knew that we HAD been able to go out on port 25 just last week, I was not happy to hear that. Naturally I asked what might have changed.
Well., "other tech person" from New Company had added a rule to their Check Point firewall. What rule? A rule to "allow outgoing port 25", he said.
Huh? That made no sense. You don't "allow" outgoing unless you are blocking outgoing and are adding some exception. For example, you might block all outgoing 25 but allow one specific machine or block it but allow it to some specific place only. But no, that was the rule that was added. And then, apparently, disabled. So a rule that would have accomplished nothing useful was disabled anyway and they still couldn't telnet out on port 25.
So.. given what we knew, how was this possible?
Darned if I knew, but by now I was in my car and heading back to the office, except that I realized we were almost out of gas, so we had to stop to fill up, which cost a mind boggling $53.28. Realize that when I started driving almost fifty years ago a gallon of gas was about 27 cents. That's unimportant to this chronicle, but it did delay me a bit more and therefore is part of the exceptionally long problem resolution time.
Excuse the digression
Upon arriving home, my customer had me join him using join.me, which was kind of neat, because I had never used that before. He should have suggested that earlier, because it works nicely with my iPad, so we could have done this from the road. Good to know for the future.
Anyway, once connected to his machine, I could see that indeed we could not telnet out on port 25 as he had said. It was rejected instantly. This wouldn't affect anything but the scanner, because all the clients were ether using the Kerio Outlook Connector or authenticated SMTP, so none of them cared about port 25.
But weren't we on a Mac?
Yes, we had been on a Mac last week. I know that because I had the tech guy do "Command-Space" to bring up Terminal. So, being one of those utterly compulsive people, I had him connect to that Mac again and - son of a gun - he could telnet out on port 25 from the Mac.
Ahh. That puts a different shine on my shoes, doesn't it? It isn't the Check Point firewall blocking port 25, so it must be..
The Old Company tech guy swore at himself and brought up McAfee Security on the Windows machine. He and I both realized where we had mislead ourselves and didn't need to say anything. Ayup, there was the port 25 block. Wrong place to put it (it should be at the firewall), but a good idea. No McAfee on the Macs, so no block. Duh! Silly us.
So.. that means that there was no good reason that the scanner shouldn't work - assuming that New Company had been added to Kerio Connect's Local IP group. When we had tried SMTP last week, the Kerio had demanded authentication, but now, it should not (because we had made New Company part of the "local' group), so we tested that from the Mac and yes, the Kerio now would accept unauthenticated mail from New Company.
Therefore, unless someone had mucked with the scanner attempting to fix a problem it never really had, that device should be ready to go. Unfortunately, it was now late afternoon and there was no one available at New Company to test that for us.
We looked at the scanner settings. It apparently can also do POP before SMTP, which is another authentication method we could allow with Kerio. However, if they wanted to do that, I'd recommend only allowing POP from New Company and not anywhere else.
Just to be a stickler, I'd suggest that the firewall at New Company should block outgoing port 25 except for packets coming from that scanner. Other than that, I expect this problem has been put to bed. If nobody had tried a telnet out, we never would have wasted all this time. If we hadn't "known" that we should have been able to telnet out, we wouldn't have wasted time talking about firewall rules that had been added and disabled. If someone had been there to try the scan after New Company had been added to the local group, we never would have tried to telnet out anyway.
'You must hate troubleshooting these stupid things", my Old Company tech ventured.
No, I don't. Not at all.
I think it's fun, and being led astray is often a way to learn new things - like that Join.me iPad app, for example. That could come in very handy when a customer can't give me a VPN or RDP connection and I'm out gallivanting around.
I'm very happy to have learned about it. I'm happy that the Check Point didn't have some secret rule. I'm happy that the scanner will be working tomorrow. Why should I hate troubleshooting? I definitely do not.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2012-03-28 Anthony Lawrence