Client keepalive in Contivity

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..
4 answers Last reply
More about client keepalive contivity
  1. 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
  2. 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
  3. 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
  4. 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
Ask a new question

Read More

vpn Networking