Tonight in trying to switch out an Instagate EX firewall with a SonicWall TZ180 - an unusual problem occurred. The internal network was not responding like it should once we disconnected the Instagate from the network. You ping the machines and get responses, but you could not log into them for services. For example: We had one machine with 10.1.2.187 that runs internal FTP services. The other station had an IP of 10.1.2.132. Both machines had a subnet of 255.255.252.0. The .132 machine could ping .187 just fine with quick response. But whenever you attempt to connect to .187 via an FTP client, it times out and refuses to connect. Same thing happens with the new SonicWall plugged in. But when the Instagate is plugged back in, all machines can log into the .187 via an FTP client just fine. Another machine on the network that hosts a database and that we access via an IP address of .189 did the same thing. Took 2 minutes to connect to it with the SonicWall or without it, but with the Instagate, it's instantaneous. It makes no sense since the Instagate seems to be doing something that I am unaware of on the LAN. As just being the firewall, I'm not understanding what it has to do with a machine connecting or not connecting since all machines are on the same subnet. If anyone has any ideas or clues would be most helpful. Thank you in advance! -G

I would suspect a name resolution issue. It is not a good sign that you connect to a database server via ip. That shows a lack of name resolution configuration. Fact you can ping but not connect to services supports this hypothesis Add to that the 2 minute delay which indicates resolution was done by broadcast. Are you pointed to the gateway [instagate] for dns? Example of Oxymoron: Person who is pro life and anti sex education. Education is key to prevention. Prevent conception you prevent abortion. Abstinence training clearly isn't working.

We use IPs for everything in the server room. The reason being that the software company that provides the different applications used by all the departments here at the office only use IP for connections. There is no name resolution that takes place. We do not have an internal DNS server and never have had one. The Instagate merely relays DNS information from the ISP for internet connections. Currently on my machine, my DNS points to OpenDNS servers and not anything internally and all the applications connect just fine which would seem to eliminate a DNS/Instagate culprit. I do agree the timing issue sounds familiar to a name resolution problem, but since I'm not resolving any names for anything internally, I would think that's not the issue. Thanks, G

" my DNS points to OpenDNS servers and not anything internally and all the applications connect just fine which would seem to eliminate a DNS/Instagate culprit." This only appears to be true when the instagate is connected.. correct? Do a tracert to your ftp server with and without the instagate and let us know the results. Example of Oxymoron: Person who is pro life and anti sex education. Education is key to prevention. Prevent conception you prevent abortion. Abstinence training clearly isn't working.

You are correct, that even after changing the DNS servers to OpenDNS without the Instagate firewall in place that evening, the problem still occurred. Here is the traceroute with the Instagate attached: traceroute to 10.1.2.187 (10.1.2.187), 64 hops max, 40 byte packets 1 10.1.2.187 (10.1.2.187) 0.786 ms 0.474 ms 0.263 ms I will be disconnecting the Instagate later this week and will post that result too. The network engineer who was assisting in this setup is now wondering if it's possible that some older 3com switches we have in place might be causing a problem. In such that maybe they are relaying traffic via a MAC address perhaps and without the Instagate in place (even though the new firewall has the same IP), the traffic gets delayed or screwed up. We have a few older 3com 3C16980 Superstack 2 switches that are in place on the network. Could this be a possibility? Thanks, G