Did an IPCONFIG /all - nothing found. Did a ping for .60 with the server turned off - nothing found. Updated the firmware on the firewall, still get the message.
We are a small operation, however this server does demos of our software to O&G companies, so it can't really be shut down for too long. I'm going to try the packet sniffer option and see if that shows anything. Jay Dale I.T. Manager, 3GiG Mobile: 713.299.2541 Email: [email protected] Confidentiality Notice: This e-mail, including any attached files, may contain confidential and/or privileged information for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this e-mail and attachments, if any, or the information contained herein, is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Tuesday, April 13, 2010 10:14 AM To: NT System Admin Issues Subject: Re: Initial access to server denied, then accepted 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
