Discussion:
[Openswan Users] keepalives?
Tomasz Grzelak
2005-02-09 10:30:47 UTC
Permalink
Hello!

When a vpn client (native xp+sp2) is connected to the server (openswan 2.2.0),
I can see with 'tcpdump' incoming packets. Let's assume a client is behind
NAT, and he has just established a connection with the server, but he isn't
doing anything else.

'tcpdump' is showing short incoming udp[4500] packets once a half a minute
statistically. I assume these are the keepalive packets.
Am I right?

What option in the ipsec.conf file is responsible for how often these
keepalives are sent?
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but there was
no difference.

Maybe I've made a mistake thinking that way...
Is 'dpddelay' responsible for the keepalives? And if not, waht option is?

Regards!
Tom
Paul Wouters
2005-02-09 13:23:22 UTC
Permalink
Post by Tomasz Grzelak
When a vpn client (native xp+sp2) is connected to the server (openswan 2.2.0),
I can see with 'tcpdump' incoming packets. Let's assume a client is behind
NAT, and he has just established a connection with the server, but he isn't
doing anything else.
'tcpdump' is showing short incoming udp[4500] packets once a half a minute
statistically. I assume these are the keepalive packets.
Am I right?
I have no idea what they should be. Perhaps a full packet capture would help,
and assuming this is encrypted to the isakmp SA, you'd need to dump it from
openswan with plutodebug=all
Post by Tomasz Grzelak
What option in the ipsec.conf file is responsible for how often these
keepalives are sent?
see dead peer detection, and the options dpd*=
Post by Tomasz Grzelak
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but there was
no difference.
That is because XP does not support Dead Peer Detection (RFC3706)

Paul
t***@wktpolska.com.pl
2005-02-09 18:17:44 UTC
Permalink
Post by Paul Wouters
I have no idea what they should be. Perhaps a full packet capture would
help, and assuming this is encrypted to the isakmp SA, you'd need to dump
it from openswan with plutodebug=all
this is what 'tcdump' is telling me:
17:58:51.822273 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
17:58:52.138716 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x440000)
17:59:00.370924 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
17:59:20.279912 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
17:59:21.120472 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
17:59:21.346225 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x3c0000)
17:59:21.822494 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
17:59:21.856413 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x440000)
17:59:40.318213 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
17:59:51.824255 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
17:59:52.071058 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x440000)
18:00:00.297162 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
18:00:20.301950 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
18:00:21.121224 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
18:00:21.181729 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x3c0000)
18:00:21.824378 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
18:00:22.015683 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x440000)
18:00:40.313114 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
18:00:51.826130 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
18:00:51.988636 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x440000)
18:01:00.358342 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
Post by Paul Wouters
Post by Tomasz Grzelak
What option in the ipsec.conf file is responsible for how often these
keepalives are sent?
see dead peer detection, and the options dpd*=
that's first what I've seen at
And if I understand you well the 'dpd*' are the only options for keepalives,
right?
Post by Paul Wouters
Post by Tomasz Grzelak
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but there
was no difference.
That is because XP does not support Dead Peer Detection (RFC3706)
That explains a lot to me.
So there is no way to make an xp client send more keepalives at the same time
interval?

TIA,
Tom
Paul Wouters
2005-02-09 20:51:45 UTC
Permalink
Post by t***@wktpolska.com.pl
Post by Paul Wouters
I have no idea what they should be. Perhaps a full packet capture would
help, and assuming this is encrypted to the isakmp SA, you'd need to dump
it from openswan with plutodebug=all
17:58:51.822273 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
17:58:52.138716 aa.bb.cc.dd > xx.yy.vv.ww: ESP(spi=0x11941194,seq=0x440000)
17:59:00.370924 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
17:59:20.279912 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
So Andreas taught me something in his last post. Those are indeed keepalives
from the NAT-T connection to avoid nat routers from forgetting that udp
negotiated conenction. I didn't know about these :)
Post by t***@wktpolska.com.pl
Post by Paul Wouters
Post by Tomasz Grzelak
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but there
was no difference.
So according to Andreas it is keep_alives=3 :)

Though 3 second kep alives seem rather many to me.

Paul
--
"At best it is a theory, at worst a fantasy" -- Michael Crichton
Andreas Steffen
2005-02-09 23:03:48 UTC
Permalink
Post by Paul Wouters
Post by t***@wktpolska.com.pl
Post by Paul Wouters
I have no idea what they should be. Perhaps a full packet capture would
help, and assuming this is encrypted to the isakmp SA, you'd need to dump
it from openswan with plutodebug=all
17:58:51.822273 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
ESP(spi=0x11941194,seq=0x440000)
17:59:00.370924 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
17:59:20.279912 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
So Andreas taught me something in his last post. Those are indeed keepalives
from the NAT-T connection to avoid nat routers from forgetting that udp
negotiated conenction. I didn't know about these :)
Post by t***@wktpolska.com.pl
Post by Paul Wouters
Post by Tomasz Grzelak
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but there
was no difference.
So according to Andreas it is keep_alives=3 :)
Typo :-( The correct spelling is

config setup
nat_traversal=yes
keep_alive=3
Post by Paul Wouters
Though 3 second kep alives seem rather many to me.
Also seems excessively high to me
Post by Paul Wouters
Paul
Regards

Andreas

=======================================================================
Andreas Steffen e-mail: ***@strongsec.com
strongSec GmbH home: http://www.strongsec.com
Alter Zürichweg 20 phone: +41 1 730 80 64
CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===
Tomasz Grzelak
2005-02-10 07:16:35 UTC
Permalink
Post by Paul Wouters
Post by t***@wktpolska.com.pl
17:58:51.822273 xx.yy.vv.ww.4500 > aa.bb.cc.dd.4500: udp 60 (DF)
ESP(spi=0x11941194,seq=0x440000) 17:59:00.370924 aa.bb.cc.dd.4500 >
xx.yy.vv.ww.4500: udp 1
17:59:20.279912 aa.bb.cc.dd.4500 > xx.yy.vv.ww.4500: udp 1
So Andreas taught me something in his last post. Those are indeed
keepalives from the NAT-T connection to avoid nat routers from forgetting
that udp negotiated conenction. I didn't know about these :)
nice to know :)
Post by Paul Wouters
Post by t***@wktpolska.com.pl
Post by Tomasz Grzelak
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but
there was no difference.
So according to Andreas it is keep_alives=3 :)
so I set up in the 'roadwarrior' section keep_alives to 3, next to 8, and then
a client couldn't have established a connection no matter the value...
strange option... is it really for keepalives? ;)
or maybe this is another stuff not supported by xp?
Post by Paul Wouters
Though 3 second kep alives seem rather many to me.
I have problems with clients connecting from gprs networks - a client
connects, but when he stops working (using net apps) or just does nothing, a
connection is dropped in a minute or two. I noticed so fast connection
tearings only in the gprs network.
Some people told me, that if you send a little packets you are downgraded in
QoS in the gprs networks. I had no idea if it was true, so I wanted to check
if setting the keepalives to a small number of seconds would make a
difference.

thx,
Tom
Tomasz Grzelak
2005-02-10 07:29:56 UTC
Permalink
Post by Paul Wouters
Post by Tomasz Grzelak
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but
there was no difference.
So according to Andreas it is keep_alives=3 :)
sorry for double post, but one more thing - where can I find the complete
description of ipsec.conf options? 'man ipsec.conf' says nothing about
'keep_alives', and I think there are lots of other "hidden" values to set up.
Where are they described??

thx,
Tom
Andreas Steffen
2005-02-09 15:44:48 UTC
Permalink
NAT keep alive packets have nothing to do with Dead Peer Detection.
If NAT traversal has been activated by setting

config setup
nat_traversal=yes

then by default every 20 seconds a 1 byte-sized UDP/4500 datagram
is sent in order to refresh the table entry in the NAT-router.

The keep_alive value can be explicitly set in the config setup section:

config setup
nat_traversal=yes
keep_alive=<seconds>

Pozdrowienia

Andreas
Post by Tomasz Grzelak
Hello!
When a vpn client (native xp+sp2) is connected to the server (openswan 2.2.0),
I can see with 'tcpdump' incoming packets. Let's assume a client is behind
NAT, and he has just established a connection with the server, but he isn't
doing anything else.
'tcpdump' is showing short incoming udp[4500] packets once a half a minute
statistically. I assume these are the keepalive packets.
Am I right?
What option in the ipsec.conf file is responsible for how often these
keepalives are sent?
I wanted to have them every 3 seconds, so I set 'dpddelay' to 3 but there was
no difference.
Maybe I've made a mistake thinking that way...
Is 'dpddelay' responsible for the keepalives? And if not, waht option is?
Regards!
Tom
_______________________________________________
Users mailing list
http://lists.openswan.org/mailman/listinfo/users
--
=======================================================================
Andreas Steffen e-mail: ***@strongsec.com
strongSec GmbH home: http://www.strongsec.com
Alter Zürichweg 20 phone: +41 1 730 80 64
CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===
Jacco de Leeuw
2005-02-09 23:05:21 UTC
Permalink
Post by Tomasz Grzelak
When a vpn client (native xp+sp2) is connected to the server (openswan 2.2.0),
I can see with 'tcpdump' incoming packets. Let's assume a client is behind
NAT, and he has just established a connection with the server, but he isn't
doing anything else.
'tcpdump' is showing short incoming udp[4500] packets once a half a minute
statistically. I assume these are the keepalive packets.
I don't think you are using L2TP/IPsec but there are plenty of keep-alive
packets in that protocol. Most people enable the 'Client for Microsoft
Networks' in the TCP/IP settings. That generates lots of periodic SMB traffic
(for better or for worse). The L2TP connection itself sends a HELLO packet
every 60 seconds, with an empty data packet as response. And pppd can be
configured to send echo packets and drop the connection if the peer appears
to be dead (see lcp-echo-failure and lcp-echo-interval in man pppd).

Jacco
--
Jacco de Leeuw mailto:***@dds.nl
Zaandam, The Netherlands http://www.jacco2.dds.nl
Tomasz Grzelak
2005-02-10 07:24:54 UTC
Permalink
Post by Jacco de Leeuw
Post by Tomasz Grzelak
When a vpn client (native xp+sp2) is connected to the server (openswan
2.2.0), I can see with 'tcpdump' incoming packets. Let's assume a client
is behind NAT, and he has just established a connection with the server,
but he isn't doing anything else.
'tcpdump' is showing short incoming udp[4500] packets once a half a
minute statistically. I assume these are the keepalive packets.
I don't think you are using L2TP/IPsec
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What do you think by this?? I don't get it, but in my oppinion I am using
L2TP/IPSec... And I am rather sure about that :)
Post by Jacco de Leeuw
but there are plenty of keep-alive
packets in that protocol. Most people enable the 'Client for Microsoft
Networks' in the TCP/IP settings. That generates lots of periodic SMB
traffic (for better or for worse). The L2TP connection itself sends a HELLO
packet every 60 seconds, with an empty data packet as response. And pppd
can be configured to send echo packets and drop the connection if the peer
appears to be dead (see lcp-echo-failure and lcp-echo-interval in man
pppd).
you're right about those keepalives, there may be, but 'man ipsec.conf' also
says something about keepalives through 'dpd*' options. I thought of the udp
packets as of ipsec keepalives... maybe I thought wrong, I don't know yet.

Tom
Jacco de Leeuw
2005-02-10 10:24:01 UTC
Permalink
Post by Tomasz Grzelak
Post by Jacco de Leeuw
I don't think you are using L2TP/IPsec
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What do you think by this?? I don't get it, but in my oppinion I am using
L2TP/IPSec... And I am rather sure about that :)
Oh, sorry. I figured you were not using L2TP because 1) otherwise you would
have mentioned it and 2) there is lots of periodic traffic with L2TP/IPsec
which would drown out the 'once every 30 seconds' packets that you reported.
Post by Tomasz Grzelak
you're right about those keepalives, there may be, but 'man ipsec.conf' also
says something about keepalives through 'dpd*' options. I thought of the udp
packets as of ipsec keepalives... maybe I thought wrong, I don't know yet.
If you use L2TP/IPsec, you can forget about using those DPD parameters.
The Windows built-in IPsec client ignores DPD. I don't know if Microsoft
is doing dead peer detection at the L2TP or PPP layer instead, I haven't
looked into it yet.

Jacco
--
Jacco de Leeuw mailto:***@dds.nl
Zaandam, The Netherlands http://www.jacco2.dds.nl
Paul Wouters
2005-02-10 11:59:21 UTC
Permalink
Post by Tomasz Grzelak
sorry for double post, but one more thing - where can I find the complete
description of ipsec.conf options? 'man ipsec.conf' says nothing about
'keep_alives', and I think there are lots of other "hidden" values to set up.
Where are they described??
Unfortunately, if they are not described in the man page, they are either in
seperate README files or not described at all :(

If anyone finds an undocumented option, please either mail me or report it
as bug on http://bugs.openswan.org and I will make sure it gets added to
the man pages.

Paul

Continue reading on narkive:
Loading...