|
|
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? -- Life's short and hard, kind of like a bodybuilding elf. Jon Nelson <jnelson-openvpn@xxxxxxxxxxx> |