Jason Keltz wrote:
Hi..
I have a question about the "replay protection" with OpenVPN. As I
understand it, the OpenVPN server is not happy seeing the time of a
client change backwards in time, but it would be fine with the client
time changing forward in time. What I am wondering is how OpenVPN deals
with time changes due to say, daylight savings time where all the
connected clients would suddenly lose, say, an hour? (of course the
server would lose time as well). What would happen with connected clients?
Also -- How often does OpenVPN check for the time change? I recently
found a problem with a client connecting to my VPN that was running
ntpdate AFTER the startup of the VPN. The client did initially connect,
but after about 20 seconds would get disconnected...
Thanks for any help you can provide..
Jason.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
We do have daylight savings here in brasil. I do update the time of the
server and all my clients with ntpdate. Even when openvpn is running. I
do have an script that do a ntpdate every hour. This script is running
hourly. I never had this problem that you are reporting. I believe that
you are using either static keys or some cipher algo in the CFB or OFB
mode. From the OpenVPN manual:
--no-replay
Disable OpenVPN's protection against replay attacks.
Don't use this option unless you are prepared
to make a tradeoff of greater efficiency in exchange for
less security.
OpenVPN provides datagram replay protection by default.
Replay protection is accomplished by tagging each
outgoing datagram with an identifier that is
guaranteed to be unique for the key being used. The peer
that receives the datagram will check for
the uniqueness of the identifier. If the identifier was
already received in a previous datagram,
OpenVPN will drop the packet. Replay protection is
important to defeat attacks such as a SYN flood
attack, where the attacker listens in the wire,
intercepts a TCP SYN packet (identifying it by the
context in which it occurs in relation to other packets),
then floods the receiving peer with
copies of this packet.
OpenVPN's replay protection is implemented in slightly
different ways, depending on the key manage-
ment mode you have selected.
In Static Key mode or when using an CFB or OFB mode
cipher, OpenVPN uses a 64 bit unique identifier
that combines a time stamp with an incrementing sequence
number.
When using TLS mode for key exchange and a CBC cipher
mode, OpenVPN uses only a 32 bit sequence
number without a time stamp, since OpenVPN can guarantee
the uniqueness of this value for each key.
As in IPSec, if the sequence number is close to wrapping
back to zero, OpenVPN will trigger a new
key exchange.
To check for replays, OpenVPN uses the sliding window
algorithm used by IPSec.
I think that if you use TLS, and a cipher in CBC mode (i suggest
AES-256-CBC), you won't have these problems anymore.
My regards,