Sign in with
Sign up | Sign in
Your question

Client keepalive in Contivity

Tags:
  • VPN
  • Networking
Last response: in Networking
Share
Anonymous
June 4, 2004 12:11:13 PM

Archived from groups: comp.dcom.vpn (More info?)

All,
I have found several users who have solved their VPN client dropping problem
by turning OFF the keepalive option in the Contivity client. Is there any
way to adjust the keepalive options [in the server] to make them less
aggressive? I have not been able to find any settings at all.
Thanks for any help.
John

--
www.pccitizen.com Safe Computing, Home wired and wireless networking tips.
....You spend your whole life figuring out what you should have done with it,
let alone what it was all about. And then your children get to do it all
over again..

More about : client keepalive contivity

Anonymous
June 8, 2004 11:25:50 PM

Archived from groups: comp.dcom.vpn (More info?)

This is a group setting in the IPSec configuration. It is actually
called Client Failover Tuning and the default is 3 mins of idle time.

I think that you should think carefully about turning this value off.
The reason why this causes drops is due to NAT devices timing out the
UDP500 state out of the table when not used for a certain amount of
time. This is the setting by which the contivity knows that the client
is no longer there. If you turn it off, you are risking getting
phantom tunnels. Making the timer longer will not work either, as the
state will still have timed out of the state table. One solution is to
turn on NAT Traversal. This has a keepalive send out every 18 seconds
to keep states open.

If you decide to go with the Disabling Keepalives, I would strongly
advise that you make sure that your users are able to log in more than
once per username (tihs is in the group connectivity settings). The
reason I say this is because if they loose connectivity the Contivity
does not konw to kick them off any more. They will get kicked
eventually, but not until the rekey.

Hope this helps

Rossi




"John Loop" <jdloop@remove.bellsouth.net> wrote in message news:<gDZvc.4578$1s1.1050@bignews4.bellsouth.net>...
> All,
> I have found several users who have solved their VPN client dropping problem
> by turning OFF the keepalive option in the Contivity client. Is there any
> way to adjust the keepalive options [in the server] to make them less
> aggressive? I have not been able to find any settings at all.
> Thanks for any help.
> John
Anonymous
June 9, 2004 7:02:53 PM

Archived from groups: comp.dcom.vpn (More info?)

Rossi,
Appreciate your reply. Gradually learning good info. I understand now that
the customers behind a NAT can lose connection if the NAT UDP table times
out as a result of turning keepalives off. Never thot of that! Apparently
the keepalives run on UDP port 500?
And enabling NAT traversal actually tries to keep the UDP entry in the NAT
table from timing out by "tickling" it every 18 seconds[from the VPN server
end instead of the client end]?
Why does the NAT traversal ask me to set port info? Should I just specify
the normal port 500?

Thanks again!

J
--
www.pccitizen.com Safe Computing, Home wired and wireless networking tips.
....You spend your whole life figuring out what you should have done with it,
let alone what it was all about. And then your children get to do it all
over again..

"rossi" <rossi141@hotmail.com> wrote in message
news:a03bbd19.0406081825.6dc46650@posting.google.com...
> This is a group setting in the IPSec configuration. It is actually
> called Client Failover Tuning and the default is 3 mins of idle time.
>
> I think that you should think carefully about turning this value off.
> The reason why this causes drops is due to NAT devices timing out the
> UDP500 state out of the table when not used for a certain amount of
> time. This is the setting by which the contivity knows that the client
> is no longer there. If you turn it off, you are risking getting
> phantom tunnels. Making the timer longer will not work either, as the
> state will still have timed out of the state table. One solution is to
> turn on NAT Traversal. This has a keepalive send out every 18 seconds
> to keep states open.
>
> If you decide to go with the Disabling Keepalives, I would strongly
> advise that you make sure that your users are able to log in more than
> once per username (tihs is in the group connectivity settings). The
> reason I say this is because if they loose connectivity the Contivity
> does not konw to kick them off any more. They will get kicked
> eventually, but not until the rekey.
>
> Hope this helps
>
> Rossi
>
>
>
>
> "John Loop" <jdloop@remove.bellsouth.net> wrote in message
news:<gDZvc.4578$1s1.1050@bignews4.bellsouth.net>...
> > All,
> > I have found several users who have solved their VPN client dropping
problem
> > by turning OFF the keepalive option in the Contivity client. Is there
any
> > way to adjust the keepalive options [in the server] to make them less
> > aggressive? I have not been able to find any settings at all.
> > Thanks for any help.
> > John
Anonymous
June 9, 2004 11:36:43 PM

Archived from groups: comp.dcom.vpn (More info?)

Thats right - keepalives are ISAKMP packets (UDP 500). The actual
traffic is ESP protocol. What NAT traversal really does is
encapsulates ESP protocol into a UDP packet of your choice. So the
port it is asking about is what you want to encapsulate the tunnel
traffic into. So there are 2 parts to the tunnel, there is the UDP500
(which in reality is used to bring up, maintain and pull down the
tunnel) and then there is the real tunnel traffic. The reason behind
the encapsulation is this: ESP protocol has no ports associated with i
- this makes it difficult for NAT devices/Stateful Firewalls to track
it - especially older devices. So this was put in so that tunnels
could be set up thru these kind of stateful devices, as the tunnel
traffic would in fact now be a UDP packet.
The default used to be 10001. I see no reason not to use 10001 or any
other UDP port. I would probably try to keep away from "well knows"
ports, ie, those below 1024. I do not know what the outcome would be
is you set it to be UDP500, but I probably wouldn't do it - it might
work, but it might not (it probably would work). You are correct in
that the NAT keepalives are sent from the server side every 18
seconds, and this does indeed "tickle" the router to keep its state.
Just one word of warning. If you enable NAT traversal and you allow
the client source ports to float, some old routers cause connection
issues. D-Link 604 was one of them. You would need to upgrade the
D-Link software for this. What was happening was that the packet from
the client was comming out dst UDP500 src UDP>1024, and the router was
converting this src port to 500 and then not converting it on the way
back. Thus the client was not receiving the packet. I do not konw of
any home router that has problems with this anymore, but just wanted
to let you know that if you come accross this to upgrade the home
routers.

Rossi


"John Loop" <jdloop@remove.bellsouth.net> wrote in message news:<T4Jxc.171$ej6.7@bignews3.bellsouth.net>...
> Rossi,
> Appreciate your reply. Gradually learning good info. I understand now that
> the customers behind a NAT can lose connection if the NAT UDP table times
> out as a result of turning keepalives off. Never thot of that! Apparently
> the keepalives run on UDP port 500?
> And enabling NAT traversal actually tries to keep the UDP entry in the NAT
> table from timing out by "tickling" it every 18 seconds[from the VPN server
> end instead of the client end]?
> Why does the NAT traversal ask me to set port info? Should I just specify
> the normal port 500?
>
> Thanks again!
>
> J
> --
> www.pccitizen.com Safe Computing, Home wired and wireless networking tips.
> ...You spend your whole life figuring out what you should have done with it,
> let alone what it was all about. And then your children get to do it all
> over again..
>
> "rossi" <rossi141@hotmail.com> wrote in message
> news:a03bbd19.0406081825.6dc46650@posting.google.com...
> > This is a group setting in the IPSec configuration. It is actually
> > called Client Failover Tuning and the default is 3 mins of idle time.
> >
> > I think that you should think carefully about turning this value off.
> > The reason why this causes drops is due to NAT devices timing out the
> > UDP500 state out of the table when not used for a certain amount of
> > time. This is the setting by which the contivity knows that the client
> > is no longer there. If you turn it off, you are risking getting
> > phantom tunnels. Making the timer longer will not work either, as the
> > state will still have timed out of the state table. One solution is to
> > turn on NAT Traversal. This has a keepalive send out every 18 seconds
> > to keep states open.
> >
> > If you decide to go with the Disabling Keepalives, I would strongly
> > advise that you make sure that your users are able to log in more than
> > once per username (tihs is in the group connectivity settings). The
> > reason I say this is because if they loose connectivity the Contivity
> > does not konw to kick them off any more. They will get kicked
> > eventually, but not until the rekey.
> >
> > Hope this helps
> >
> > Rossi
> >
> >
> >
> >
> > "John Loop" <jdloop@remove.bellsouth.net> wrote in message
> news:<gDZvc.4578$1s1.1050@bignews4.bellsouth.net>...
> > > All,
> > > I have found several users who have solved their VPN client dropping
> problem
> > > by turning OFF the keepalive option in the Contivity client. Is there
> any
> > > way to adjust the keepalive options [in the server] to make them less
> > > aggressive? I have not been able to find any settings at all.
> > > Thanks for any help.
> > > John
Anonymous
June 10, 2004 11:46:34 AM

Archived from groups: comp.dcom.vpn (More info?)

Great info, Rossi. Thanks.
We also went thru the problem where the routng table was apparently
changing, and the client would tear down the connection because of this.
Many ways that the routing table could change depending on the particular
situation!
And then we still had problems, and people then noticed that turning off
keepalives solved their problem.
John
--
www.pccitizen.com Safe Computing, Home wired and wireless networking tips.
....You spend your whole life figuring out what you should have done with it,
let alone what it was all about. And then your children get to do it all
over again..

"rossi" <rossi141@hotmail.com> wrote in message
news:a03bbd19.0406091836.24feee3f@posting.google.com...
> Thats right - keepalives are ISAKMP packets (UDP 500). The actual
> traffic is ESP protocol. What NAT traversal really does is
> encapsulates ESP protocol into a UDP packet of your choice. So the
> port it is asking about is what you want to encapsulate the tunnel
> traffic into. So there are 2 parts to the tunnel, there is the UDP500
> (which in reality is used to bring up, maintain and pull down the
> tunnel) and then there is the real tunnel traffic. The reason behind
> the encapsulation is this: ESP protocol has no ports associated with i
> - this makes it difficult for NAT devices/Stateful Firewalls to track
> it - especially older devices. So this was put in so that tunnels
> could be set up thru these kind of stateful devices, as the tunnel
> traffic would in fact now be a UDP packet.
> The default used to be 10001. I see no reason not to use 10001 or any
> other UDP port. I would probably try to keep away from "well knows"
> ports, ie, those below 1024. I do not know what the outcome would be
> is you set it to be UDP500, but I probably wouldn't do it - it might
> work, but it might not (it probably would work). You are correct in
> that the NAT keepalives are sent from the server side every 18
> seconds, and this does indeed "tickle" the router to keep its state.
> Just one word of warning. If you enable NAT traversal and you allow
> the client source ports to float, some old routers cause connection
> issues. D-Link 604 was one of them. You would need to upgrade the
> D-Link software for this. What was happening was that the packet from
> the client was comming out dst UDP500 src UDP>1024, and the router was
> converting this src port to 500 and then not converting it on the way
> back. Thus the client was not receiving the packet. I do not konw of
> any home router that has problems with this anymore, but just wanted
> to let you know that if you come accross this to upgrade the home
> routers.
>
> Rossi
>
>
> "John Loop" <jdloop@remove.bellsouth.net> wrote in message
news:<T4Jxc.171$ej6.7@bignews3.bellsouth.net>...
> > Rossi,
> > Appreciate your reply. Gradually learning good info. I understand now
that
> > the customers behind a NAT can lose connection if the NAT UDP table
times
> > out as a result of turning keepalives off. Never thot of that!
Apparently
> > the keepalives run on UDP port 500?
> > And enabling NAT traversal actually tries to keep the UDP entry in the
NAT
> > table from timing out by "tickling" it every 18 seconds[from the VPN
server
> > end instead of the client end]?
> > Why does the NAT traversal ask me to set port info? Should I just
specify
> > the normal port 500?
> >
> > Thanks again!
> >
> > J
> > --
> > www.pccitizen.com Safe Computing, Home wired and wireless networking
tips.
> > ...You spend your whole life figuring out what you should have done with
it,
> > let alone what it was all about. And then your children get to do it
all
> > over again..
> >
> > "rossi" <rossi141@hotmail.com> wrote in message
> > news:a03bbd19.0406081825.6dc46650@posting.google.com...
> > > This is a group setting in the IPSec configuration. It is actually
> > > called Client Failover Tuning and the default is 3 mins of idle time.
> > >
> > > I think that you should think carefully about turning this value off.
> > > The reason why this causes drops is due to NAT devices timing out the
> > > UDP500 state out of the table when not used for a certain amount of
> > > time. This is the setting by which the contivity knows that the client
> > > is no longer there. If you turn it off, you are risking getting
> > > phantom tunnels. Making the timer longer will not work either, as the
> > > state will still have timed out of the state table. One solution is to
> > > turn on NAT Traversal. This has a keepalive send out every 18 seconds
> > > to keep states open.
> > >
> > > If you decide to go with the Disabling Keepalives, I would strongly
> > > advise that you make sure that your users are able to log in more than
> > > once per username (tihs is in the group connectivity settings). The
> > > reason I say this is because if they loose connectivity the Contivity
> > > does not konw to kick them off any more. They will get kicked
> > > eventually, but not until the rekey.
> > >
> > > Hope this helps
> > >
> > > Rossi
> > >
> > >
> > >
> > >
> > > "John Loop" <jdloop@remove.bellsouth.net> wrote in message
> > news:<gDZvc.4578$1s1.1050@bignews4.bellsouth.net>...
> > > > All,
> > > > I have found several users who have solved their VPN client dropping
> > problem
> > > > by turning OFF the keepalive option in the Contivity client. Is
there
> > any
> > > > way to adjust the keepalive options [in the server] to make them
less
> > > > aggressive? I have not been able to find any settings at all.
> > > > Thanks for any help.
> > > > John
!