Traceroute on port 25

[hongman]

Hi all

Does anyone know of a program that can do a tracert on port 25? The amount of times I have been troubleshooting SMTP flow problems where I wish I could see where it was failing...

Thanks in advance!

Hong

[Tuttle]

You'd need an implementation of TCP traceroute -- regular traceroute utils send UDP or ICMP traffic.

That said, I think traceroute is going to be pretty much useless in troubleshooting SMTP issues, unless it's obvious that one server isn't even making a TCP connection to another (something you can determine with the logs and/or netstat). It's far more often something mangling the traffic within the SMTP session -- something like an old Cisco PIX doing SMTP "fixup" or an MTU issue which allows the SMTP conversation to happen fine but then loses the message content (which is typically larger packets).

[hongman]

Thanks Tuttle

The reason I ask is becuase of this scenario which happens often ish, and I have wondered about such a tool for a long time.

Recently mail flow stopped just like that at a client site.

The mail flow went like this:

Internet --> Fortinet FG500 --> Proofpoint SPAM Filter --> Exchange BH

The FG500 had a history of being 'buggy' at times. So we didnt rule that out to have fallen ove again.

The proofpoint was exhibiting signs of not working properly also, though minor.

A telnet connection to Port 25 to the clients external IP fails.

If I had a tool that could trace on port 25, then I could easily work out if it is indeed even hitting the Proofpoint box, or if its failing at the firewall.

In the end I had to trawl through logs and do TCP dumps to detemine if any traffic was reaching the Proofpoint box.

I have had other similar scenarios like this where I think that kind of tool would be handy, and speeding up the process. I know you can accomplish this in other ways but its just something I thought someone might have already done!

[hongman]

In fact, tuttle, how would you have diagnosed it? It'll interesting to see how a true expert in the field would have handled it.

In the end to the above, it turned out that the quarantine db on the Proofpoint had got too big and caused some odd behaviour, so it was updated to the latest firmware and cleared out.

The firewall was also a culprit beucase I had changed the Virtual IP for the Proofpoin address to port 22 to allow remote SSH, and fogot to change it back!

[Tuttle]

For troubleshooting that sort of thing, nothing beats a laptop running Ethereal. Connect into somewhere interesting (in your case between the Fortinet and Proofpoint boxes) and just see what's going across the wire.

Connecting in varies depending on environment. The low-tech way is to just splice in a 10 Mbps hub where you want to listen (yes, those things still have a use ). In a higher-end environment you'd normally make sure those potentially-interesting links go through a VLAN on a managed switch, and then be able to listen to the traffic on another port with a basic switch reconfiguration.

[hongman]

Aha, something like port mirroring to sniff the traffic?

[Tuttle]

Exactly that, depending on what your switch vendor calls it.

[hongman]

thanks tuttle