When you can't trust tcpdump

| 2 Comments
I just spent a good chunk of today bothering the telecom people to try and figure out why one server of mine couldn't talk to any off campus NTP servers. I had two servers, one was talking just fine, the other wasn't. For proof, I had packet traces showing that the non-working server was not getting an appropriate "ntp server" return packet.

And yet, after the telecom people sniffed the border firewall connections they saw UDP/123 packets on both sides. In other words, it transited the firewall just peachy. And also our IDS/IPS. So, clearly it was getting in. But it wasn't showing up on the tcpdump output on the server.

Then about 15 minutes ago I turned off the "restrict default ignore" line on that server.

And it started syncing off campus just fine. With packets.

WHY was tcpdump not showing the packets? That's what I want to know! Somehow, the UDP packets were being dropped before tcpdump saw them. Strange.

2 Comments

Wow, that is strange. You might check the config and see if there was a filter of some kind applied directly to the card/binding. That's the only thing I can think of, that it would be rejecting packets before it got past that layer on the OSI. Freaky.

A similar thing happened to me after upgrading some servers to FreeBSD 7. Turned out it was a bug in bpf.