Add support for checking and submitting HIP reports
Unlike CSD, the HIP security checker runs during the connection phase, not
during the authentication phase.
Therefore we need to build the CSD token (an MD5 digest identifying the
client) without relying on the authentication phase having run in the same
process.
We build it from the cookie containing authentication information,
but exclude the volatile field (which changes from session to session)
and the preferred-ip field (which may not be present in all cases, or may
change from session to session).
Signed-off-by: Daniel Lenski <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
Most of the existing ESP support code (written for Juniper/nc) can be reused
for GlobalProtect ESP. The ESP algorithms, SPIs, and keys are sent as part of the
getconfig XML response.
GlobalProtect requires a fairly awkward "tap dance" between the TCP mainloop and
the UDP mainloop in order to support ESP:
* Prior to the getconfig XML request, the HTTPS tunnel will not work (even though
the authcookie is already known from the login response) and the ESP tunnel
also will not work (because the ESP keys are not known).
* After the getconfig XML request, either the ESP tunnel or the HTTPS tunnel can
be connected, but not both. As soon as the HTTPS tunnel is disconnected,
the ESP keys are invalidated. On the other hand, if the ESP tunnel stops
responding due to some firewall that interferes with UDP, the HTTPS tunnel
can still be connected.
* Therefore, in order to allow the ESP tunnel to start, the TCP mainloop must
refrain from actually connecting to the HTTPS tunnel unless the ESP tunnel
is disabled or has failed to connect... but it can't wait *too* long
because then the HTTPS keepalive connection may be dropped, and the user
will wonder why no traffic is flowing even though the VPN has allegedly
started. The wait time is currently hard-coded at 5 seconds (half the DPD
interval used by the official clients).
Another quirk of the GlobalProtect ESP support: it uses specially
constructed ICMP request/reply ("ping") packets as the probes for ESP
initiation and DPD.
* These packets must contain a "magic payload" in order to work.
* In most GlobalProtect VPNs, the packets are addressed to the public, external IPv4
address of the VPN gateway server even though they are sent over the ESP
tunnel (???), but in some cases they must be addressed to a different address
which is misleading described as <gw-address> in the getconfig XML response.
Don't blame me. I didn't design this.
GlobalProtect also has the strange quirk that incoming (server → client) ESP
sequence numbers start at 1, not 0, but this just causes a one-time offset
for the replay protection checker.
Signed-off-by: Daniel Lenski <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
add PAN GlobalProtect protocol support (HTTPS tunnel only)
This includes support for generating an xmlconfig so that NetworkManager can
list all the gateway servers, when connecting to a GlobalProtect portal (not
gateway):
GlobalProtect distinguishes "portal" and "gateway" servers. Often the same
server supports both (/global-protect URLs are for the portal, /ssl-vpn URLs
are for the gateway). The official clients always connect through the
portal. Mostly, the portal configuration is not useful for OpenConnect; it
restricts the behavior of the official clients.
However, the portal configuration does contain a list of allowed gateways
(just as AnyConnect VPNs can list other servers). We therefore generate an
xmlconfig in the same format as AnyConnect VPNs, so that the NetworkManager
plugins can list all the supported gateways.
Signed-off-by: Daniel Lenski <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
detect user[name], pass[word] form fields using only the first 4 characters
The current process_auth_form_cb hard-codes the interpretation of these form
fields based on their names. GlobalProtect has identical fields but with
slightly different names.
Signed-off-by: Daniel Lenski <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
fix a bug leading to incorrect split-include netmasks
This bug was my fault. Introduced in 881eb286499baf78afbaeff4dbc5f055d23f1e4f on 15 Oct 2016 ("Correctly handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24")
Left shift of >=32 bits is undefined on x86 (https://stackoverflow.com/a/7471843/20789), and it was causing split-includes of 0.0.0.0/0 to output inconsistent values to
the vpnc-script variables for split-includes:
CISCO_SPLIT_INC_12_MASKLEN=0
CISCO_SPLIT_INC_12_ADDR=0.0.0.0
CISCO_SPLIT_INC_12_MASK=255.255.255.255 # generated by netmaskbits() in script.c -- WRONG!
Save latest ESP sequence number even if replay protection isn't in use
In the current source, incoming ESP sequence numbers
(vpninfo->esp_in[vpinfo->current_esp_in].seq) are not actually tracked at
all unless replay protection is in use.
At the time of a rekey, old_esp_maxseq is *set based on the current value of
the incoming seq* at the time of the switchover:
if (new_keys) { vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
And then esp.c rejects packets with the old incoming SPI, unless seqp < old_esp_maxseq:
This code is supposed to allow a smooth handover from the old incoming SPI
to the new one after a rekey, so that in-flight packets from the old SPI
aren't totally dropped, but also aren't allowed to continue forever.
This patch tracks the latest sequence number even if ESP replay protection
isn't in use -- however inadvisable that may be -- allowing the handover to
work correctly.
This patch also improves the confusing trace message shown when a packet
from the old SPI is received.
[dwmw2: Just call verify_packet_seqno() every time, and let it return an
artificial 'success' when replay protection is turned off. Also
add changelog entry.]
Signed-off-by: Daniel Lenski <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
