«

Hello,

Can anybody help me with the following:

For one of out customers i've created a vpn connection between two
outlets with pix 501 firewalls. Both outlets are using the pix for
internet access too. Also both pixes have a dialin option for the
cisco vpn client configured.

Some users from 1 outlet connect there telnet-terminals through the
vpn to the unix server located in the other outlet. This is where the
problem rises.

All works fine as long as everyone stays at work and continues working
on their terminals. But if a user stops working for some time (i'm not
sure about how long this period is, maybe lunch-time, so half an
hour???) the telnet session gets broken. When the user returns he has
to reconnect to the unix hist again, login again etc, etc.

Before the vpn was introduced, the putlets were connected via a leased
line. At that time there were no problems. Since nothing else changed,
only the outlet connection has been replaced by the vpn, i believe the
error comes from the pixes. I've looked at some timeout values in the
pixes, but i have no clue of what to look for exactly.

Can anybody please give me some hints???

Thanks!!!!!!!
Ernie

In article <>,
ernie <> wrote:
utlets with pix 501 firewalls. Both outlets are using the pix for

:All works fine as long as everyone stays at work and continues working
n their terminals. But if a user stops working for some time (i'm not
:sure about how long this period is, maybe lunch-time, so half an
:hour???) the telnet session gets broken. When the user returns he has
:to reconnect to the unix hist again, login again etc, etc.

Is it possible that the users are taking a longer lunch than that?
What you are describing sounds like the 'conn' (connection) timeout
kicking in. That defaults to 1 hour. 'show timeout' and look for 'conn'.

http://www.cisco.com/univercd/cc/td/...tz.htm#1026093
--
The Knights Of The Lambda Calculus aren't dead --this is their normal form!

Not sure on this, but I have seen it as well.

First telnet is not very forgiving and a vpn over the internet doesn't
always keep telnet happy. Thus is terminates. We use a terminal server and
it works well.

Second, the VPN has a lifetime. 86400 (secs?) I think by default. After
this life time, it must recreate itself (again "I think"). Therefore
"unhappy" applications may drop during this re-creation time.

Given this, try to ping continuosly from one side to the other and see if
the tunnel drops. It should not, (because traffic is still flowing) thus if
telnet drops and the pings do not, try something more forgiving ie: terminal
server. If you send no traffic over for a given period of time, and the
tunnel drops, the tunnel will need to be regenerate before allowing traffic
to go through it.

Hope this helps. If anyone has ideas, I'm ears.

thanks
Brad


"ernie" <> wrote in message
news:...
> Hello,
>
> Can anybody help me with the following:
>
> For one of out customers i've created a vpn connection between two
> outlets with pix 501 firewalls. Both outlets are using the pix for
> internet access too. Also both pixes have a dialin option for the
> cisco vpn client configured.
>
> Some users from 1 outlet connect there telnet-terminals through the
> vpn to the unix server located in the other outlet. This is where the
> problem rises.
>
> All works fine as long as everyone stays at work and continues working
> on their terminals. But if a user stops working for some time (i'm not
> sure about how long this period is, maybe lunch-time, so half an
> hour???) the telnet session gets broken. When the user returns he has
> to reconnect to the unix hist again, login again etc, etc.
>
> Before the vpn was introduced, the putlets were connected via a leased
> line. At that time there were no problems. Since nothing else changed,
> only the outlet connection has been replaced by the vpn, i believe the
> error comes from the pixes. I've looked at some timeout values in the
> pixes, but i have no clue of what to look for exactly.
>
> Can anybody please give me some hints???
>
> Thanks!!!!!!!
> Ernie

Oops, forgot.

Remember that the XLATE table will timeout conns. Therefore if you are
PATting addresses, this could confuse the remote host. Also it is pretty
safe to say that is the XLATE table timesout, then the Telnet one would
break as well, since no traffic is passing to tell the host to keep the
session alive.

sh xlate is helpful for this.

"Brad Hazelbaker" <> wrote in message
news:3fd7906b$0$62191$...
> Not sure on this, but I have seen it as well.
>
> First telnet is not very forgiving and a vpn over the internet doesn't
> always keep telnet happy. Thus is terminates. We use a terminal server
and
> it works well.
>
> Second, the VPN has a lifetime. 86400 (secs?) I think by default. After
> this life time, it must recreate itself (again "I think"). Therefore
> "unhappy" applications may drop during this re-creation time.
>
> Given this, try to ping continuosly from one side to the other and see if
> the tunnel drops. It should not, (because traffic is still flowing) thus
if
> telnet drops and the pings do not, try something more forgiving ie:
terminal
> server. If you send no traffic over for a given period of time, and the
> tunnel drops, the tunnel will need to be regenerate before allowing
traffic
> to go through it.
>
> Hope this helps. If anyone has ideas, I'm ears.
>
> thanks
> Brad
>
>
> "ernie" <> wrote in message
> news:...
> > Hello,
> >
> > Can anybody help me with the following:
> >
> > For one of out customers i've created a vpn connection between two
> > outlets with pix 501 firewalls. Both outlets are using the pix for
> > internet access too. Also both pixes have a dialin option for the
> > cisco vpn client configured.
> >
> > Some users from 1 outlet connect there telnet-terminals through the
> > vpn to the unix server located in the other outlet. This is where the
> > problem rises.
> >
> > All works fine as long as everyone stays at work and continues working
> > on their terminals. But if a user stops working for some time (i'm not
> > sure about how long this period is, maybe lunch-time, so half an
> > hour???) the telnet session gets broken. When the user returns he has
> > to reconnect to the unix hist again, login again etc, etc.
> >
> > Before the vpn was introduced, the putlets were connected via a leased
> > line. At that time there were no problems. Since nothing else changed,
> > only the outlet connection has been replaced by the vpn, i believe the
> > error comes from the pixes. I've looked at some timeout values in the
> > pixes, but i have no clue of what to look for exactly.
> >
> > Can anybody please give me some hints???
> >
> > Thanks!!!!!!!
> > Ernie
>
>

Thanks for your quick response!

Is this connection timeout a per user timeout? Cause only the 'lunch
breaking' users get disconnected. Other users, which are working
harder for the same money don't get discnonnected.

If this is a per user parameter, then this must be the problem, i
checked the config and it is at the default 1 hour.

In that case, what would you advise? Set it to infinite?

Thanks again!

Op 10 Dec 2003 21:23:29 GMT schreef
(Walter Roberson):

>In article <>,
>ernie <> wrote:
>utlets with pix 501 firewalls. Both outlets are using the pix for
>
>:All works fine as long as everyone stays at work and continues working
>n their terminals. But if a user stops working for some time (i'm not
>:sure about how long this period is, maybe lunch-time, so half an
>:hour???) the telnet session gets broken. When the user returns he has
>:to reconnect to the unix hist again, login again etc, etc.
>
>Is it possible that the users are taking a longer lunch than that?
>What you are describing sounds like the 'conn' (connection) timeout
>kicking in. That defaults to 1 hour. 'show timeout' and look for 'conn'.
>
>http://www.cisco.com/univercd/cc/td/...tz.htm#1026093

In article <>,
ernie <> wrote:
:Is this connection timeout a per user timeout? Cause only the 'lunch
:breaking' users get disconnected. Other users, which are working
:harder for the same money don't get discnonnected.

It isn't per-user, it is per connection. A connection which is idle
for the 'conn' timeout period will have its status dropped at the PIX,
but there will be no RST sent to either end.

:If this is a per user parameter, then this must be the problem, i
:checked the config and it is at the default 1 hour.

:In that case, what would you advise? Set it to infinite?


Sounds like you have a potential security problem, if users are
going to lunch and leaving their computers active and connected
to a remote resource. A longer timeout might not be the best way
to approach this problem.

If you do decide to go with a longer timeout, then I would suggest
no greater than the length of the working day unless there is a real need
to be able to keep connections going overnight (and if that's the case,
then the 'screen' program might be of use to you.)
--
Suppose there was a test you could take that would report whether
you had Free Will or were Pre-Destined. Would you take the test?

In article <3fd7906b$0$62191$>,
Brad Hazelbaker <> wrote:
:Second, the VPN has a lifetime. 86400 (secs?) I think by default. After
:this life time, it must recreate itself (again "I think"). Therefore
:"unhappy" applications may drop during this re-creation time.

No, the renegotiation of the IKE is done -before- the tunnel would
expire, so there is no break in service.

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

In article <3fd79172$0$30475$>,
Brad Hazelbaker <> wrote:
:Oops, forgot.

:Remember that the XLATE table will timeout conns. Therefore if you are
ATting addresses, this could confuse the remote host. Also it is pretty
:safe to say that is the XLATE table timesout, then the Telnet one would
:break as well, since no traffic is passing to tell the host to keep the
:session alive.

No, the xlate entries do not time out as long as there are active
connections. The xlate timeout does not start ticking until after the
conn timeout has come into effect.
--
When your posts are all alone / and a user's on the phone/
there's one place to check -- / Upstream!
When you're in a hurry / and propagation is a worry/
there's a place you can post -- / Upstream!