Add openconnect_set_requested_ip() and --request-ip to explicitly request specific IP addresses
Protocol support:
- GlobalProtect supports requesting either Legacy IP or IPv6 addresses.
- Some Cisco AnyConnect servers *maybe* support this, but ocserv does not.
- PPP-based protocols might support this for Legacy IP *if* their IP
address negotiation is purely via PPP/IPCP; PPP/IP6CP can't actually
request a complete 16-byte IPv6 address.
- No known way to provide it for Juniper, Pulse, Array.
Currently, this option is only a request. OpenConnect will print an error
message, but will not abort, if the server assigns a different IP address.
The openconnect_set_requested_ip() API function carefully parses user-input
requested IP addresses using inet_pton(), and then renormalizes them using
inet_ntop(). This will avoid warnings about IP address mismatch where the
requested address doesn't match the quad-dotted notation for IPv4 or CIDR
notation for IPv6.
We assume that any real VPN server that provides IP addresses in text form
adheres to one of these two normalizations (see https://gitlab.com/openconnect/openconnect/merge_requests/35#note_174395447), but
perhaps we *should* do similar for server-provided IP addresses too,
since we've had problems with this in the past.
Signed-off-by: Daniel Lenski <email address hidden>
I *suspect* that 'internal=no' is the implicit default if unspecified
(https://gitlab.com/openconnect/openconnect/-/issues/246#note_836128670),
but we should get more testing on other GlobalProtect VPNs to confirm that
this works fine with them. If there is variation in whether this parameter
is allowed/expected, then we need a way to automatically detect the correct
value.
Signed-off-by: Daniel Lenski <email address hidden>
Fix initial client request XML structure when announcing multicert capability
Having a separate 'announce_multicert_capability' function wasn't ideal:
1. Building the initial '<config-auth>' XML was more spread out and complex
than necessary due to an extra layer of functions.
2. When multicert auth is offered by the client, the resultant XML actually
contained *two* nested capabilities/auth-method tags:
What Cisco clients appear to send is a *single* '<capabilities>' tag
containing multiple '<auth-method>', as shown in the MITM capture in the
comments of
f51ecb36bedcd370086586295978627daeabade4 ("Converse the multiple certificate authentication (multicert) protocol."),
which introduced this structural mistake.
With the non-repeated '<capabilities>' tag, we can also fix the multicert
auth tests, where the check that the client was offering multicert was
disabled in
45da3b07dfc8f808e7b0d0bf80fbf7e73b1b0721 ("fake-cisco-server.py: Disable check for `multiple-cert` support"),
probably due to confusion over the XML structure and xmltodict's handling
of it.
Signed-off-by: Daniel Lenski <email address hidden>
