On Tue, Apr 13, 2010 at 9:48 AM, Jay Dale <[email protected]> wrote:
> It could be a case where the second server is thinking the IP of
> the application is the firewall instead.

  Even if that second server was confused like that (which I suppose
is possible), it shouldn't cause the firewall to claim the first
server's IP address.  Hmmm.

  Okay, let's back up and review what we know and what that tells us.

  (A1) We know the server at 192.168.0.60 is complaining of a
duplicate IP address, and the MAC address that server gives is the
same as the firewall's MAC address.

  Does the server at 192.168.0.60 have any additional IP addresses
configured?  Even if you don't think so, if you haven't checked
recently, run "IPCONFIG /ALL" on the .60 server to see if something
happened without your knowledge.

  Assuming the server at .60 has only that single IP address....

  I believe the A1 message occurs when the server in question sees an
ARP reply from another host, for an IP address configured locally.
So, either (B1) the firewall emitted that ARP reply, or (B2) something
else is spoofing the firewall's MAC address and emitting the ARP
reply.

  I would consider B2 to be fairly unlikely.  That generally is either
(C1) malice, or (C2) deliberate jiggery-pokery done on a network
interface to satisfy some other broken thing (like application
software licensed to a particular MAC address).  You're small enough
that C1 seems unlikely, and you'd presumably know if C2 was being
done.  So that leaves B1.

  Reasons I can think of for B1 are: (D1) Firewall is configured with
192.168.0.60 as a secondary IP address.  (D2) Firewall is doing proxy
ARP for another node, and that other node is configured with
192.168.0.60 as an IP address.  (D3) Firewall malfunction.

  Have you tried unplugging the "real" .192.168.0.60 server, and then
pinging 192.168.0.60 to see if something else answers?  That would
definitely be a good next step.  It should easily spot D1 or D2.

  Do you have the latest firmware loaded for the firewall?  Possibly
this is D3, and it's a bug fixed by a newer firmware.

  Possibly it is worth clearing NVRAM on the firewall, resetting it to
factory defaults, and re-creating the configuration from scratch.
Don't reuse an existing config file.  This is a pain, but again, you
seem to be a small operation (5 people, you said), so not *that* much
of a pain.  And if something is corrupt on the firewall, or some
obscure configuration item someone accidentally tripped over is
causing the problem, this will likely clear it.  I'd think this more
likely to fix something than just changing the nominal IP address of
the firewall from 192.168.0.2 to something else.

  If none of the above helps, I would prolly start using a packet
sniffer to watch what's actually happening on the network.  Use an
independent computer, start sniffing just before the real
192.168.0.60, and see if that bogus ARP reply shows up.  Then start
backtracking to see where it's coming from.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to