Hi Daniel,
Good news.
On Sat, 27 Jul 2024 11:04:40 -0700
Daniel Lenski <dlen...@gmail.com> wrote:
> On Thu, Jul 25, 2024 at 4:59 PM Karl O. Pinc <k...@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@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@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 <k...@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. :-)
_______________________________________________
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
