Debugging UDP ESP failure

[Karl O. Pinc]

Hi Daniel,

Good news.

On Sat, 27 Jul 2024 11:04:40 -0700
Daniel Lenski <dlenski at gmail.com> wrote:

> On Thu, Jul 25, 2024 at 4:59 PM Karl O. Pinc <kop at karlpinc.com> wrote:
> > Thanks for the reply.  Here's the info you asked for.
> > It looks like the proprietary client sets up a UDP VPN
> > and openconnect does not.  
> 
> Thanks. From your detailed log I have an idea of what's going on:

> OpenConnect is reporting "did not receive ESP keys and matching
> gateway in GlobalProtect config". The "matching gateway" part is key.
> 
> Your VPN is indeed showing a previously unanticipated case, where the
> VPN sends an IPv6 magic ping address
> ("<gw-address-v6>REDACTEDIPV6ADDRESS7</gw-address-v6>") but it
> *doesn't* send an IPv6 client address (there is no "<ip-address-v6>").
> In that case, we need to use the IPv4 magic ping address even though
> we NORMALLY prefer the IPv6 magic ping address, because that one is
> required if we want to be able to use both IPv6 and IPv4.
> 
> I put together a fix for this in
> https://gitlab.com/openconnect/openconnect/-/commits/handle_GP_ESP_magic_address_corner_case
> 
> Can you please build and test that? I don't have a real GP VPN that I
> can test it on anymore, unfortunately.

Works for me.  The output includes:

  ESP session established with server
  ESP tunnel connected; exiting HTTPS mainloop.
  Configured as READACTEDIPV4NUMBER, with SSL disconnected and ESP established

And I see the expected UDP traffic go through the firewall. Thanks!

Let me know if you need anything else.

---

Various notes for your records follow, just in case anything matters:

---

I had to apply my patches on top of yours:
https://gitlab.com/openconnect/openconnect/-/merge_requests/564

---

For whatever reason, probably because of some failure during a
previous test, there were "extra" net interfaces in existence
after the first time I tried to setup the VPN.  "ip link" output
included:

8: tun0-vpnssh0 at if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ee:96:fd:5d:2e:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0
10: veth0 at if11: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 82:84:36:33:5c:c3 brd ff:ff:ff:ff:ff:ff link-netns vpnc-script-sshd

and part of the openconnect output included:

  Session authentication will expire at Sun, 28 Jul 2024 15:24:56 CDT
  RTNETLINK answers: File exists
  RTNETLINK answers: File exists
  VPN now accessible through 'ssh fec0::1'

The result of this seemed to be a ESP VPN session, but one
that didn't forward any packets after `ssh fec0::1`.  Everything
that happened in the network namespace just stayed there without
touching the VPN.

This sort of thing has to do with some failure mode of vpnc-script-sshd,
in my experience.

After deleting the interfaces tun0-vpnssh0 and veth0 everything worked
as expected.  I tried twice.  Each time worked, and afterwards there
were no "extra" interfaces left lying about.  So, all good.

---

FYI, I couldn't find a "clean*" target that did not leave files
for git to add.  The best I could do was `make maintainer-clean`,
which left me with:

$ git status
On branch gp_double_SAML_udp
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	compile
	config.h.in
	m4/libtool.m4
	m4/ltoptions.m4
	m4/ltsugar.m4
	m4/ltversion.m4
	m4/lt~obsolete.m4
	tests/test-obsolete-server-crypto.config.27841.tmp
	tests/test-obsolete-server-crypto.config.27906.tmp

So I started with `./autogen.sh` and when on to run ./configure
from there.  Everything built, `make check` passed, and the result
has worked.  So, no worries. (To be more precise, all the checks
passed but "FAIL: auth-certificate", because I don't have the
necessary libraries/packages installed to build that feature.)

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

P.S.  So nice to be able to test without fighting with the proprietary
client.  :-)