One possible clue:

The symptoms you describe are somewhat similar to a poisoned ARP cache,
e.g if the default route's ARP entry is wrong.  Using a local 'ping' to
recover can help, but not all the time. See if a 'arp -d <IP>' helps,
either using an on-lan IP, or the IP of the default gateway, depening on
the host you 'ping'.

On some occasions, running tcpdump on an interface can "fix" such a
problem, as the interface get put in promiscuous mode, meaning it listens
to all packets, not just those with the correct MAC destination. This
causes packets with the correct *IP* to be recieved by the system,
regardless of MAC dest.

When you exit tcpdump, the interface is returned to normal state.

I'd check the ARP tables, and try to figure out what may be causing the
bad entries, if you find such. For instance, before running tcpdump, is
the ARP entry of the routers IP really the routers MAC? If not, could be
an attacker has gained entry to a system located on the same LAN as your
router and firewall (not a good network design, for this reason).

If it is this problem, you may be able to prevent it from occuring again
by using static/permanent ARP entries for the important machines on the
LAN. Read the manual page for arp on how to do this, I think NetBSD has
this feature. Note that on most OSes (primarily not *BSD), "static" does
just mean it does not time out, not that it cannot be overwritten by an
attacker.

/H

On Sun, 7 Oct 2001, Seth Kurtzberg wrote:

> I am seeing a strange problem that occurs frequently after running tcpdum=
p.
> The machine exhibiting the problem is part of a firewall, and thus is
> forwarding packets, using ipf, ipnat, and running some proprietary proxy
> software.
>
> After running tcpdump, the machine becomes unreachable over the net.  It
> doesn't respond to ping requests, doesn't route packets, and just general=
ly
> appears dead with respect to networking.  This is true for both interface=
s.
>
> Most of the time, if I get on the machine (using the console) and ping it=
s
> neighbors, it recovers; perhaps the routing tables are repopulated by the
> pings?  If the pings don't make it work, it is necessary to stop and rest=
art
> the routing daemon.  Thus far stopping and restarting the routing daemon =
has
> always worked.
>
> I'm thinking that perhaps the way I shut tcpdump down is related to the
> problem.  (I've been using control-c at a shell prompt in an xterm.)  I t=
ried
> shutting down tcpdump using kill -15, but this did not change the behavio=
r
> (that is, the routing problems still appear after running tcpdump).
>
> I've not seen this problem running tcpdump in other environments (Solaris=
,
> Linux, Windoz).
>
> Any clues?

--
H=E5kan Olsson <ho@crt.se>        (+46) 708 437 337     Carlstedt Research
Unix, Networking, Security      (+46) 31 701 4264        & Technology AB