Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[puas]

I have local & remote users running win XP/ICE-TCP PRO v. 5.1.21 connecting to server running sco openserver v5.x. The local side and server are sitting behind a 3com officeconnect firewall (running NAT) and a cisco 827 ADSL router.

The local users connect and keep there connections indefinately, while the remote users connect but subsequently drops anywhere from 15 mins to 3 hours (the longest i've held a connection).

I've run the NETSTAT command on both the Client (XP) & Server (Unix) side and the XP side seems to keep the connection open while the Unix side seems to close it. I've tried establishing connectionsfrom remote locations via DSL, through different ISPs, SBC, Verizon, covad, with the same results.
I've also tried making a connection from one of the ports on the router with the same results.

My assumption is that the server is trying to determine the status of the connection with the client but either the Firewall and/or router is dropping the connection after remaining idle. Ive set the firewall timeout setting to 8 hours (480 mins). I'm having trouble trying to access the cisco, i'm not very familiar with the cisco language (<<<got to be an engineer to access a cisco!!!)

Does the server send some type of packet to check on the connection? if so, via which protocol/port....etc?

Any ideas on how to troubleshoot this further?
Any help would be greatly appreciated, as this has been torturing me for 3 months!!!!!!!!!!!!

Thanks,

Puas

[Bob]

Update to the current version and try turning on the keepalive function.
(search for keepalive in the forums for more info).

[puas]

thanks, bob,

For testing purposes, I'm trying to understand how this KEEPALIVE works. Is the Keepalive sent by the server, client or both?

I plan on removing all my users from the firewall and seting up a conection with a Client (xp) on the WAN side and the Server (unix) on the LAN side to determine if the fiirewall is the root of my problems. I'll do the same setup with the router. I'll keep you posted.

thanks

Puas

[puas]

Bob,

I did a search for "keepalive" and it returned my post and your reply only....am i missing something?

puas

[Bob]

Look for more than 60 days worth of entries

[puas]

ok, tried the 60+ days search and got some results.

Last question, other that the KEEPALIVE, is there another mechanism keeping the local connections open that may be getting comprimised for the remote connections?

I'm trying to log the traffic between the server<->firewall<->client to determine where and or what is causing it!!!

I'm at my witt's end


puas

[Bob]

No, there is no other mechanism. The connection is being taken down when you are using remote connections by either a timeout on the VPN (if you have one) a NAT timeout (if you have one) a timeout by the DSL provider or a inconsistent and/or bad internet connection on either end. You really never see these types of problems on a lan. Lan's don't need keepalives!
The only other thing I can think of that would mess you up is if you had a dynamic IP address on the remote and the ISP is forcing it to change periodically. If the address changes while you are using the connection you will lose the connection. The keepalive in PRO if enabled MIGHT be able to prevent this. It depends on if the ISP DHCP server pays attention to use of the existing address before changing it or not.

[puas]

Bob,
thanks for all your help!

I ran a test overnight and I have some good results.

I moved a Client pc to the WAN side of the Firewall...
Client<->Cisco<->Firewall<->Server...and it held the connection overnight.

my 3 remote user's all have the following connection...
Client<->Netgear<->DSL modem<->INTERNET<->Cisco<->Firewall<->Server... with the Netgear RP614 in common to all 3.

Also, on a previous test, I connected the Client to a Netgear<->cisco...etc, to simulate the connection equipment-wise, and the connection dropped.
In all situations, the Netgear appears to be at fault.

I just need to determine how to set/change the "timeout" on these Netgears.

Thanks

Puas

[puas]

bob,

just wanted to update my last post....After some frustrating hours, I've determined that the netgear is the root of my problem. So I purchased 2 additional routers (Dlink #DI604 & LinkSys #BEFSX41) as possible replacements, with the same resulsts (dropped telnet).

I did a search for this issue on google and found the following article...
http://www.netsoc.tcd.ie/~higels/dg814_timeout.html

It appears my suspicions were correct....I'll be purchasing an SMC Barricade 7004VBR and doing some additional testing....?

I'll keep this updated.

[Bob]

Nice job testing it out. Good to hear you tracked it down. You might want to check to see if there is firmware update for the netgear as well.

[puas]

bob,

FOUND my solution. All these "home networking" routers were the cause of my problem. apparently they clear their "NAT Table" after the connection remains idle for a certain amount of time (<). So i finally bit the bullet and purchased a cisco 831 Ethernet router and connected it to a cable modem. Works like a charm, albeit the cisco configuration was a headache in itself!

I have another question....I'm trying to run the SSH on the server and it runs for less than 2 minutes and the application shuts down. Any ideas?

Thanks
puas

[Bob]

That sounds suspiciously like the other timeout. Did you try updating to version 5.1.25,  installing it and turning the keepalive on? It works for both telnet AND ssh connections.

[puas]

diffrent problem....with the telnet, the routers on the remote end were dropping the connection (the cisco took care of that). with the SSH, the service (daemon?) shuts down on the Server....not running more than than a couple minutes. the Telnet service never shutdown on the Server....it was the connection on the remote router dropping.

consequently, I've never been able to establish an SSH connection because it never runs long enough to try.

puas

[Bob]

How do you know that the daemon is shutting down by itself and not simply because the connection is timed out by an intervening router? The SSH server may be better able to notice when the connection has been dropped than the telnet daemon.

When running SSHD on the unix side you should use a relatively recent version. The sco pd 3.1 version wasn't too good.

[puas]

our Unix system administrator installed and configured the SSH....and he tells me that the Daemon runs for a couple minutes and then stops.

I'll check with him about which version he's running.