Nope, but I think I found the issue - or at least have not received any more messages.
Before I started using Wireshark to sniff what the problem could be, I started poking around the Sonicwall. Since it turned out that no other server was affected, I had no intention of changing the LAN ip per their instructions. Going through the NAT policies, I found one that was a failed one-to-one NAT setup that was still enabled. I removed that policy totally and left the one that was originally set up to do loopback for the application. Since removing that one-to-one policy, I have not had any more issues. So I guess that was causing the problem. Thanks for the help guys! 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: Ames Matthew B [mailto:[email protected]] Sent: Thursday, April 15, 2010 6:38 AM To: NT System Admin Issues Subject: RE: Initial access to server denied, then accepted No one running a VM with a DHCP server operating inside it? -----Original Message----- From: Jay Dale [mailto:[email protected]] Sent: 13 April 2010 14:48 To: NT System Admin Issues Subject: RE: Initial access to server denied, then accepted I have gone through each office and have determined there are no devices or equipment doing DHCP. I am also in agreement that switching the IP on the LAN side will not solve the issue, although I will be trying it this afternoon. I do have a theory on what could be causing it, however. We have an application that we develop that is hosted on that .60 server. At one point within the software, you can pull up maps and geographical locations from an ArcGIS server, which is a different IP. The application actually goes out to our FQDN and back into the network on a different port and hits that server to pull up the map information. It could be a case where the second server is thinking the IP of the application is the firewall instead. Again, this is just a theory, but I've checked everywhere else and have not found anything that could be causing the situation. 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: John Aldrich [mailto:[email protected]] Sent: Tuesday, April 13, 2010 7:41 AM To: NT System Admin Issues Subject: RE: Initial access to server denied, then accepted I tend to agree. I think you'll find that someone has *something* plugged in that is doing DHCP. Whether they realize it or not, they've caused this problem. I'd suggest going around and unplugging any piece of SOHO equipment that you did not personally install and configure, one by one, and then see if after unplugging each one (and with the "offending server" unplugged,) you can still ping the IP address of the server. -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Monday, April 12, 2010 4:15 PM To: NT System Admin Issues Subject: Re: Initial access to server denied, then accepted On Mon, Apr 12, 2010 at 4:02 PM, Jay Dale <[email protected]> wrote: > Wifi is 10.0.1.0/24, Sonicwall is 10.0.1.1. DHCP range on local is between > .100 and .200, same for wifi. The IP for the server is .60 that keeps > rejecting ... Okay, given what you've said so far, I don't think changing the IP address of the SonicWall on the wired network is likely to help anyway. If the SonicWall is mistakenly doing proxy ARP, or otherwise configured to claim an additional incorrect address, it would keep doing so. I don't know why they suggest that. (Unless the SonicWall support folks are just engaged in some "shotgun debugging": "The making of relatively undirected changes to software in the hope that a bug will be perturbed out of existence. This almost never works, and usually introduces more bugs." (Jargon File)) If you can, I'd suggest taking the server that keeps rejecting, and unplugging it from the LAN. Then use a different computer (still plugged into the LAN) to try ping'ing 192.168.0.60 and see if anything answers. If it does, you can start tracing there. :-) > ... in the Sonicwall ARP cache it is listed with the correct MAC address. ARP caches are generally overwritten as soon as a new answer comes in. Since the problem is intermittent, it could be that when the failure mode occurs, the ARP cache in the Sonicwall would show something different, but by the time you can check it, that bogus answer has been replaced. > And we only have 5 guys in this office, and I've walked around and > asked - they're all developers and are fairly knowledgeable about what > I ask them (for the most part - they are developers you know...:)) Hmmm. Well, they might not realize that combination print-server/coffee-maker they got at Staples is also a DHCP server. Or, they could just be flat-out lying. But I guess we'll take their word for it for now. :) -- 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: 85 Buckingham Gate, London SW1E 6PD http://www.qinetiq.com. ~ 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/> ~
