]> www.infradead.org Git - users/dwmw2/openconnect.git/commit
Newer Pulse servers can disable their ESP protocol layering malpractice
authorDaniel Lenski <dlenski@gmail.com>
Sun, 23 Oct 2022 18:17:28 +0000 (11:17 -0700)
committerDaniel Lenski <dlenski@gmail.com>
Sat, 25 Feb 2023 18:08:49 +0000 (10:08 -0800)
commit7bbbc9cd04bf55bf6503d13192a0140d0fdc12ee
tree807dbec4c0f4a5cbf59427d9fc5ff31a7a43afed
parent46420c080bc949ccd63976cf852f3593d73c2303
Newer Pulse servers can disable their ESP protocol layering malpractice

See b4f50f8bd5da7e6ac926ddd5095501edbc204cd0 for the way that the Pulse ESP
tunnel is mangled.  In brief, if the Pulse ESP tunnel is running over IPvX,
then it will only transport tunnelled packets of address family IPvX;
tunnelled packets of IPvY must go over the TLS/TCP tunnel.

In addition to being a complete inversion of the abstraction of a protocol
with independent layers:

- This results in poor performance for tunnelled IPvY packets (TCP-over-TCP)
- Our original implementation of this caused a regression for the
  Juniper/NC ESP tunnel (fixed in 3d1ec6e0a126d4b9fdd18473558cf816d2045b76).

As reported in http://lists.infradead.org/pipermail/openconnect-devel/2020-October/004934.html
and https://gitlab.com/openconnect/openconnect/-/issues/506, newer Pulse
servers starting with 9.1R9 can apparently use the ESP tunnel in a sane way,
if the administrator sets a flag labelled "Use ESP tunnel for 6in4 and 4in6
traffic".

OpenConnect should try to coax the server to use this saner tunnel setup
if possible.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>
esp.c
openconnect-internal.h
pulse.c
www/changelog.xml