Guinea pig needed! Do you have access to a GP VPN supporting IPv6?

[dlenski]

I've attempted to add IPv6 support in the ipv6 branch. The necessary changes are fairly straightforward, and newer GP VPNs (PanOS≥8.0) and official clients (≥4.0) do support IPv6.

However, I don't actually have a GP VPN that supports IPv6 to test it with myself :-1:.

If anyone has access to a GP VPN with IPv6 support, please check out and test this branch in the maximum logging mode.

(ping @kamazee @jonesbf because you both have posted logs that suggest your VPNs have IPv6 support)

$ openconnect --protocol=gp -vvvv --dump $SERVER $USUAL_STUFF

If you get that far, here are some questions:

1. Can you share the parts of the log from /global-protect/getconfig.esp which contain IPv6 routing information?
2. Does IPv6 routing get configured correctly?
3. And the bottom line… can you actually send/receive packets with IPv6 hosts inside the VPN? (Try ping6-ing a couple, for instance.)
4. If you pause and restart the connection (killall -USR2 openconnect) does it reconnect properly without complaining?
5. If your VPN requires a HIP report… does that work correctly with IPv6?

[kamazee]

have posted logs that suggest your VPNs have IPv6 support

AFAIR, I thought that "6" in "days until the password expires" implied IPv6 support which didn't appear to be true. We don't have IPv6 in our VPN to the best of my knowledge.

[dlenski]

Thanks, @kamazee … it wasn't because of the "6"… it was because the <exclude-access-routes> section in your getconfig.esp indicates that your VPN is on a recent version of the server software :-D

[lhanson]

I'm fairly sure my VPN supports IPv6; I see an IPv6 address assigned to my tun0 interface after I connect, if that's any indication.

I checked out the ipv6 branch and ran it as instructed, however it doesn't seem to work. My network stack is left in an indeterminate state where I'm unable to connect to anything.

connect.log

[dlenski]

I checked out the ipv6 branch and ran it as instructed, however it doesn't seem to work. My network stack is left in an indeterminate state where I'm unable to connect to anything.

Thanks for trying this, @lhanson. Sorry I overlooked this reply.

1. It looks like your VPN does not support IPv6. The XML config doesn't hand you an IPv6 address (your OS may be providing a dummy one).
2. The "indeterminate state" is most likely caused by the VPN requiring HIP (but you didn't include --csd-wrapper=${PATH_TO_HIPREPORT_SCRIPT}, so it didn't run).

There is something strange going on with ESP on your VPN. ESP doesn't work and it fails over to HTTPS. Does ESP work with the official Win/Mac client?

Send ESP probes
Connected as 146.151.217.37, using SSL
Received ESP packet of 40 bytes
Received ESP packet with invalid HMAC
Received ESP packet of 40 bytes
Received ESP packet with invalid HMAC
Received ESP packet of 40 bytes
Received ESP packet with invalid HMAC
No work to do; sleeping for 1000 ms...
No work to do; sleeping for 4000 ms...
Connecting to HTTPS tunnel endpoint ...
> GET /ssl-tunnel-connect.sslvpn?authcookie=fc0c4e6dd1a4b9cce6fc7956061672c2&user=[REDACTED] HTTP/1.1
> 

[lhanson]

What are the consequences of ESP not working?

Unfortunately I don't have ready access to a windows or mac machine, so I'm not sure if it works with the official client.

[dlenski]

What are the consequences of ESP not working?

VPN is slower, especially with a lossy or congested underlying network because tcp-over-tcp.

There are lots of GlobalProtect VPNs out there where ESP is nonfunctional due to IT borking the configuration of some internal firewall, so the ESP packets can't actually get in/out. I've just never seen a case where the ESP packets are getting HMAC'ed wrong. ¯\_(ツ)_/¯

[dlenski]

OpenConnect has had complete* support for GlobalProtect IPv6 (we think!) for a while now, since MR!188.

Closing this :rocket: :partying_face: