Laurence F. Sheldon, Jr. wrote:

Though not the same circumstances on having the same symptoms as the OP's problem, I saw this happen once at a University I used to work for. A system's administrator insisted on having a hub between the SP's router and our core campus switch so he could sniff traffic. Since the hub was there and I couldn't eliminate it I went ahead and used it myself for my own traffic capture point in the network with an OS X box running EtherPeek. I did an OS update on the box one morning and went to a meeting. During the meeting it was reported that the network was down. I started looking into the problem at that point. All Internet traffic was dead except SSH connections. So I started sniffing on my NOC server for that server's traffic. All my outbound TCP connections from the NOC were getting a RST from one L2 host and a SYN-ACK from another. The MAC address sending the RST looked familiar but I couldn't identify it. After searching through the network for the MAC I found it on the interface facing our border router and that damn hub. The MAC was my OS X sniffing box. The other MAC was the backside of the provider's router.

The OS X update I applied was the one that installed a host-based firewall. The update automatically turned on the FW and permitted all local servers that were configured to run, in my case SSH, with everything else being denied. The FW on the OS X box normally wouldn't see packets not destined for it until you put a nic in promisc mode such as what happens when you run EtherPeek. The OS X box's FW was getting hits from traffic denied by it's ACL and was sending TCP RSTs faster than hosts on the 'Net could respond. It did this for everything except SSH which it permitted (but higher up the IP stack it ignored because the IP packet was address to the local box).

This isn't in any way related to the problem at hand but it does demonstrate that weird things happen when devices in unusual places flood out all ports.

Justin