Our main IT guy is out of the office, so I have to (quickly) resolve this urgent issue. No one in the company is receiving external emails. It seems to have just happened suddenly. We have an AD domain, using Exchange Server 2003, with a Barracuda 300 Spam & Firewall box as our inbound firewall. When I look at the Barracuda admin page, it shows messages having come in and processed for hours and then all of a sudden no messages, starting a few hours ago. In Exchange System Manager, there are a ton (hundreds or more) of SMTP connections between Exchange and the Barracuda box. Barracuda support is currently looking at the problem but finding nothing so far. Any ideas as to what this might be? Something from the Exchange side? Thanks in advance for any help.

EDIT: If I do a traceroute from an external address, it never reaches my firewall. I see the packets go from router to router on the internet, but the last router listed is Comcast, my ISP. It doesn't show our hardware firewall at all, so I'm thinking maybe the mail is never making it to the Barracuda box (and thus, on to the mail server).

| improve this question | | | | |
  1. Perform a DNS lookup for the MX record for your email domain.

  2. If step 1 succeeds then perform a DNS lookup for the A record returned from the MX record lookup.

  3. If step 2 succeeds then try to establish a telnet session to port 25 of the ip address returned from the A record lookup.

  4. If step 3 succeeds then try to send an email to an internal user from the telnet session established in step 3.

  5. If step 4 succeeds then you know the problem is between the Barracuda and the Exchange server.

  6. If the Barracuda has any type of CLI then try to establish a telnet session from it to port 25 of your Exchange server.

  7. If step 6 succeeds then try to send an email to an internal user from the telnet session established in step 6.

  8. If step 7 succeeds then you know the problem is with the Exchange server.

Let us know which step, if any, fails so can help you narrow down the problem.

I think I've covered all the bases. If anyone sees anything I've left out, please pipe up.

| improve this answer | | | | |
  • Thanks a lot. I was able to do steps 1-3, but on Step 4, after sending the message, the response I got instead of "250 OK" was "250 Mail queued for delivery". I haven't yet received the message. Also, the barracuda support tech was unable to telnet to port 25 of my mail server. I should note that we have a Watchguard firewall that sits between our cable modems and the Barracuda box. I just looked at the Watchguard traffic monitor and I see a ton of messages and they all have "msg=Connect timeout" listed in the message field. So I'm assuming that's the problem but not sure where to go with it. – johnnyb10 Aug 4 '10 at 23:34
  • @johnnyb10, if that's the case, then I would recommend calling Watchguard support. It sounds like port 25 is being blocked or NAT'd incorrectly. Maybe something as simple as a reboot of the firewall will fix it, but I would call support. – Holocryptic Aug 5 '10 at 0:32
  • Yeah, I called them about four and half hours ago (and a couple of times since) but they still have yet to have an available technician. Meanwhile, our entire company is getting zero external emails. Grr. – johnnyb10 Aug 5 '10 at 0:40
  • The status message you got in step 4 is actually normal. The incoming messages get queued before they're sent to the information store. Is the ip address in step 2 the ip address of the Baracuda, or the firewall, or the Exchange server? Also as Holo suggested, I would recommend a reboot of the firewall as well. – joeqwerty Aug 5 '10 at 2:19

First off, if you have Barracuda support looking into it, let them do their thing. They know what they are doing and have handled issues like this in the past.

In my experience, if the Barracuda is sitting on emails that it has already accepted, there are only a couple of things that can be wrong.

First, there might be a problem with the connection to the Exchange server, in that the exchange server isn't accepting them or is tempfailing them for some reason (like, for example, your store being full and unmounted). THere are also some edge cases where if the Barracuda is validating inbound emails against your AD zone before accepting them and your connection to the AD server is broken, you can see a delay -- but the most common failure mode for this problem is that the mail gets perma-bounced rather than tempfailed or queued.

Second, there might be a flood of incoming messages/spam happening, and the Barracuda is spending time dealing with the flood rather than passing the messages along. You can see this by looking at the statistics graphs on the admin page -- big spike means big traffic.

There is also the possibility that your Barracuda has a hardware problem and is fighting, say, a failing disk internally. If that's the case then support will figure that out fairly quickly.

But really, let support do their thing.

| improve this answer | | | | |
  • Thanks. How would I deal with the issue of Barracuda not connecting to AD? – johnnyb10 Aug 4 '10 at 21:22
  • Also, Barracuda support did not help. They said that the mail doesn't appear to be reaching the Barracuda box, so it's not something they can help with. – johnnyb10 Aug 4 '10 at 22:12
  • What's the logging interface of the Barracuda telling you through all this? – David Mackintosh Aug 5 '10 at 15:47

Silly question, maybe, but: have you power-cycled the Barracuda devices yet? We don't use their SMTP device, but our Barracuda Web Filter goes haywire at least twice a month -- e.g. suddenly blocking all web traffic without explanation -- and rebooting it always resolves the problem. Of course, you should shut it down from the administrative interface if at all possible rather than just pulling the plug.

WatchGuard firewall edit:

I was not previously aware that this was behind a WatchGuard firewall. This detail is worth adding to the original question.

I have personal experience with inbound e-mail mysteriously disappearing into the voracious jaws of a Firebox. Is it configured with a packet filter on port 25, or an SMTP proxy? In my experience, the SMTP proxy has three modes of operation: (1) normal operation, (2) selective snacking on e-mail from important clients, and (3) devouring all incoming e-mail. Unfortunately, the mode selection is random and is not user-configurable. It also has a serious security drawback in that it prevents opportunistic TLS connections, causing e-mail to be sent in plaintext when it normally would be encrypted. This may or may not matter in your specific environment.

Especially given that you already have another e-mail firewall product, if you are using the WatchGuard SMTP proxy, I would strongly suggest changing it to a simple packet filter.

| improve this answer | | | | |
  • Yes, I did reboot the Barracuda device and the Watchguard device. At this point, Watchguard says that it's sending traffic through, but nothing is showing up on the Barracuda box. – johnnyb10 Aug 5 '10 at 11:53
  • See edit above. Do not trust the WatchGuard SMTP proxy. – Skyhawk Aug 5 '10 at 15:28
  • 1
    I second this sentiment. I've seen the WatchGuard proxy do exactly this in the past. – sysadmin1138 Aug 5 '10 at 15:36
  • +1 for documenting the three random modes of WatchGuard SMTP Proxy operation! – BillN Aug 11 '10 at 20:53

I'd say first verify connectivity from outside. Go to mxtoolbox.com and enter your domain name, click submit. The tool will do a DNS lookup of the MX records for your domain. You should see a record for your barracuda or exchange server. There will be a link to test/diagnose, click it. This will attempt to open a telnet session over port 25 to the server to verify that it is reachable and responding. This should tell you were to go next. Note that the TraceRoute does not necessarily mean there is a problem, as the barracuda is likely configured to not answer ICMP requests.

| improve this answer | | | | |
  • Thanks for the advice. I used mxtoolbox.com and it seems to do a successful DNS lookup, but it fails the SMTP test. What would cause that to happen? – johnnyb10 Aug 4 '10 at 22:55
  • A simple telnet session like in JOEQWERTY's answer would work, but I'd try it from outside the firewall, so you can ensure that remote servers can reach your mailserver. So try it from home, starbucks, wherever, as long as you are not on your network. – BillN Aug 11 '10 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.