|
|
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 |