Debugging UDP ESP failure
Daniel Lenski
dlenski at gmail.com
Sat Jul 27 11:04:40 PDT 2024
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:
> POST https://vpnhost.example.com/ssl-vpn/getconfig.esp
> > POST /ssl-vpn/getconfig.esp HTTP/1.1
> > Host: vpnhost.example.com
> > User-Agent: PAN GlobalProtect
> > Cookie: PHPSESSID=0d908f7158db4981ddb0a77a0333afcb; CLIENTOS=V2luZG93cw%3D%3D
> > X-Pad: 000000000000000000000000000000000000000000000000000000000
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 327
> >
> > client-type=1&protocol-version=p1&internal=no&app-version=5.2.13-48&ipv6-support=no&clientos=Windows&os-version=win&hmac-algo=sha1%2cmd5%2csha256&enc-algo=aes-128-cbc%2caes-256-cbc&authcookie=1ae1b6537c0b886eabff1091c6433944&portal=gp-staff-faculty-ext-getway-N&user=REDACTEDUSER%40example.com&domain=%28empty_domain%29&computer=slate
> Got HTTP response: HTTP/1.1 200 OK
> Date: Thu, 25 Jul 2024 21:47:42 GMT
> Content-Type: application/xml; charset=UTF-8
> Content-Length: 2352
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> X-FRAME-OPTIONS: DENY
> Strict-Transport-Security: max-age=31536000;
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src * data:; style-src 'self' 'unsafe-inline';
> HTTP body length: (2352)
> <
> < <response status="success">
> < <need-tunnel>yes</need-tunnel>
> < <ssl-tunnel-url>/ssl-tunnel-connect.sslvpn</ssl-tunnel-url>
> < <portal>gp-staff-faculty-ext-getway-N</portal>
> < <user>REDACTEDUSER at example.com</user>
> < <quarantine>no</quarantine>
> < <lifetime>86400</lifetime>
> < <timeout>10800</timeout>
> < <disconnect-on-idle>10800</disconnect-on-idle>
> < <bw-c2s>1000</bw-c2s>
> < <bw-s2c>1000</bw-s2c>
> < <gw-address>REDACTEDIPV4ADDRESS7</gw-address>
> < <gw-address-v6>REDACTEDIPV6ADDRESS7</gw-address-v6>
> < <ipv6-connection>no</ipv6-connection>
> < <ip-address>REDACTEDIPV4ADDRESS0</ip-address>
> < <netmask>255.255.255.255</netmask>
> < <ip-address-preferred>yes</ip-address-preferred>
> < <dns-v6>
> < <member>REDACTEDIPV4ADDRESS1</member>
> < <member>REDACTEDIPV4ADDRESS2</member>
> < <member>REDACTEDIPV4ADDRESS3</member>
> < <member>REDACTEDIPV4ADDRESS4</member>
> < <member>REDACTEDIPV6ADDRESS1</member>
> < <member>REDACTEDIPV6ADDRESS2</member>
> < </dns-v6>
> < <dns>
> < <member>REDACTEDIPV4ADDRESS1</member>
> < <member>REDACTEDIPV4ADDRESS2</member>
> < <member>REDACTEDIPV4ADDRESS3</member>
> < <member>REDACTEDIPV4ADDRESS4</member>
> < </dns>
> < <wins>
> < </wins>
> < <dns-suffix>
> < <member>example.com</member>
> < </dns-suffix>
> < <default-gateway>REDACTEDIPV4ADDRESS0</default-gateway>
> < <mtu>0</mtu>
> < <no-direct-access-to-local-network>no</no-direct-access-to-local-network>
> < <access-routes>
> < <member>0.0.0.0/0</member>
> < <member>REDACTEDIPV4ADDRESS1/32</member>
> < <member>REDACTEDIPV4ADDRESS2/32</member>
> < <member>REDACTEDIPV4ADDRESS3/32</member>
> < <member>REDACTEDIPV4ADDRESS4/32</member>
> < </access-routes>
> < <access-routes-v6>
> < <member>::/0</member>
> < </access-routes-v6>
> < <exclude-access-routes>
> < </exclude-access-routes>
> < <exclude-access-routes-v6>
> < </exclude-access-routes-v6>
> < <ipsec>
> < <udp-port>4501</udp-port>
> < <ipsec-mode>esp-tunnel</ipsec-mode>
> < <enc-algo>aes-128-cbc</enc-algo>
> < <hmac-algo>sha1</hmac-algo>
> < <c2s-spi>0x5F672823</c2s-spi>
> < <s2c-spi>0x9FCCE331</s2c-spi>
> < <akey-s2c>
> < <bits>160</bits>
> < <val>4822b9bc1129308917434b8779fc1b5b2b93a491</val>
> < </akey-s2c>
> < <ekey-s2c>
> < <bits>128</bits>
> < <val>12e4597fc6b3a161e67be1cb27d80534</val>
> < </ekey-s2c>
> < <akey-c2s>
> < <bits>160</bits>
> < <val>fffcfca75dad43a42b56babb9c317ff1cb1020e9</val>
> < </akey-c2s>
> < <ekey-c2s>
> < <bits>128</bits>
> < <val>80fc6f79af6635c3253b1e5bbf48a068</val>
> < </ekey-c2s>
> < </ipsec>
> < </response>
> Tunnel timeout (rekey interval) is 180 minutes.
> Idle timeout is 180 minutes.
> Did not receive ESP keys and matching gateway in GlobalProtect config; tunnel will be TLS only.
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.
More information about the openconnect-devel
mailing list