[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Very strange replay problem


  • Subject: Re: [Openvpn-users] Very strange replay problem
  • From: "James Yonan" <jim@xxxxxxxxx>
  • Date: Wed, 2 Jun 2004 17:11:29 -0000

Jon Nelson <jnelson-openvpn@xxxxxxxxxxx> said:

> On Wed, 2 Jun 2004, James Yonan wrote:
> 
> > Jon Nelson <jnelson-openvpn@xxxxxxxxxxx> said:
> >
> > >
> > > I'm running 1.6.0-2 (Debian) and 1.6.0-0.1 (build myself for SuSE).
> > >
> > > I had a very strange problem about a week ago.
> > >
> > > I did some hardware futzing on the SuSE machine and rebooted it.
> > > When it came up, none of the network stuff worked.
> > > A few reboots later, I determined the cause to be OpenVPN - it was
> > > seemingly working fine on the SuSE machine, but on the Debian machine
> > > the OpenVPN daemon was complaining thusly:
> > >
> > > Wed May 26 23:36:41 2004 151[0]: Authenticate/Decrypt packet error: bad
> > > packet ID (may be a replay): [ #92688 /
> > > time = (1085632475) Wed May 26 23:34:35 2004 ] -- see the man page entry
> > > for --no-replay and --replay-window for more info
> > >
> > > Over and over again.  Over the course of 45 minutes, the SuSE box
> > > couldn't initiate a connection to the Debian box (the SuSE box is the
> > > client, forgot to mention that).
> > >
> > > The configs are very simple. I'm using a pre-shared static key, tun,
> > > float (stupid NAT'ing router between the two boxes) and not much else.
> > > As it turns out, I had to remove the state file (replay-persist file)
> > > and restart the Debian's daemon.  I tried restarting both daemons
> > > several times with no luck.
> > >
> > > Initially, the client side had a 'ping 5' option, but I moved that up to
> > > 'ping 15' and then later 'ping 30' just in case the the pings were
> > > causing some strange interaction with the replay file sliding window.
> > >
> > > What went wrong?
> >
> > No, the pings should not affect the replay window.
> >
> > Did the problem clear up when you deleted the replay state file?
> 
> Yes, the problem cleared up immediately after I deleted the replay file,
> then (re-)started OpenVPN (on the server side).
> 
> > Aside from actual replay attacks, there are a few things that can cause replay
> > false alarms:
> >
> > * Packet duplication occurring in the network link because of badly configured
> > routers.
> 
> The link is a wireless link using a Prism card.  With heavy volume, I
> get a non-negligible number of duplicate warnings.
> 
> > * System clock backtracking.  If you start openvpn to connect to a peer, stop
> > it, move your system clock backward in time, and then restart openvpn, you
> > will get errors like this.
> 
> On the server or client side?  The client was rebooted several times.
> However, with each reboot, the client sets its time (after OpenVPN has
> started), and the system (hardware) clock should have been very close to
> correct.
> 
> > * High latency links such as satellite links which can cause a greater amount
> > of packet reordering and therefore needs a larger sliding window size.
> 
> Again, this is over wireless.
> 
> This has only happened once, but it certainly was annoying.  More
> annoying was that I couldn't get OpenVPN to "clear" it up by itself,
> despite almost 45 minutes of restarts and idle time.
> 
> What could I change or what should I look for?

Spurrious replay warnings can sometimes be fixed by increasing the replay
sliding window size using the --replay-window directive.  I've seen postings
on the IPSec mailing lists that satellite links can require a window size of
2048. 

Increasing the window size is the solution if the replay warnings are caused
by significant packet reordering over the network.

If the replay warnings are caused by duplicated packets, you should still have
connectivity, and you can suppress the messages using --verb or --mute

Otherwise if you're still having the warnings, there's either some kind of
clock backtracking issue or even possibly a bug in the replay code (though
this code has been stable for quite a while, so I would mostly discount this
possibility).

In order to debug, you would have to use a high --verb level and show the
Packet IDs of the packets going over the wire.  The Packet ID has a time-stamp
+ integer sequence number.  The receiver will issue a warning and reject the
packet if either time-stamp steps backward, or sequence number steps backward
while time-stamp stays the same.

You can always disable replay checking with --no-replay, but that would reduce
security and deprive you of getting to the bottom of the issue.

James