On Sun, Apr 19, 2020 at 12:05 PM The Wanderer <wanderer@xxxxxxxxxxx> wrote:
>
> On 2020-04-19 at 14:30, Daniel Lenski wrote:
>
> > On Sun, Apr 19, 2020 at 4:54 AM The Wanderer <wanderer@xxxxxxxxxxx>
> > wrote:
> >> Judging from what I can see, this OpenConnect version may not even
> >> be trying to switch to HTTPS at all; it just keeps waiting and
> >> retrying on ESP, and eventually replies to older ESP packets start
> >> coming in and things sync back up and work again.
> >>
> >> If this causes any noticeable lag or other discrepancies in my
> >> actual VPN connection, I don't recall them.
> >
> > There aren't any code changes I can see that would explain this, we
> > didn't do anything to fix such behavior, and I don't see any
> > evidence of that in the logs you attached.
>
> ...then I'm not sure what the "later-than-expected" and "out-of-order"
> ESP packet references in the log excerpt from 8.05 are about, if they
> don't qualify as evidence that the client stayed with 8.05 and kept
> retrying and eventually got responses to older packets.
I don't know what “stayed with 8.05” means, but it's making me worried
that your setup is even more complex than I've gathered so far.
>
> > Also, replying to wrong/older ESP packets on a regular basis would
> > jam up your VPN connection thoroughly, and OpenConnect has an ESP
> > replay-protection mechanism that would be complaining ("replayed
> > packet" in the logs) if it were receiving packets significantly out
> > of order.
>
> I don't know about "significantly", but I certainly interpret "Accepting
> out-of-order ESP packet" as indicating that it has received a packet
> that was not in the expected order.
>
> The order received from the previous log excerpt was 2, 1, 3, 5, 4, 6,
> after which it went back to monotonic increments; packet 0 doesn't seem
> to have shown up at all.
There's nothing here.
A small number of *slightly* out-of-order packets is completely normal
in any IP network or datagram-based protocol.
For whatever reason, yours appears to have more than some. There is no
plausible mechanism by which this has *anything* to do with the
version of OpenConnect you're running. These are simply packets sent
by the VPN server which arrive at your local host slightly out of
order, and OpenConnect notices this, logs the fact that they're
slightly out-of-order while checking that they're not being replayed
(https://en.wikipedia.org/wiki/Replay_attack), and otherwise proceeds
normally.
_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel
