Skip to content

bugfix: don't ignore /0 routes included in "split" routes

Daniel Lenski requested to merge dlenski/NetworkManager-openconnect:do_not_ignore_plen=0_in_split_routes into master

This bug particularly affects users of GlobalProtect VPNs:

  • The way that most VPNs (Cisco vpnc, Cisco AnyConnect, Juniper, Pulse) advertise a default route is by saying "my default IPv4 netmask is 0.0.0.0" (or IPv6 equivalent).

  • For whatever reason, the way that GlobalProtect VPNs are configured to advertise a default route is different. They almost always set a default netmask of 255.255.255.255, and then include "0.0.0.0/0" among the list of split routes.

    Here's an extract from a GlobalProtect /ssl-vpn/getconfig.esp response illustrating the problem clearly:

    <response status="success">
    <ip-address>10.0.0.101</ip-address>
    <netmask>255.255.255.255</netmask>
    <dns>
        <member>10.0.2.2</member>
        <member>10.0.2.3</member>
    </dns>
    <access-routes>
        <member>0.0.0.0/0</member>
        <member>10.0.2.2/32</member>
        <member>10.0.2.3/32</member>
    </access-routes>
</response>

    When OpenConnect v8.0+ parses this config, it results in the following environment variables being sent to the vpnc-script …

    INTERNAL_IP4_ADDRESS=10.0.0.101
INTERNAL_IP4_NETMASK=255.255.255.255
CISCO_SPLIT_INC=3
CISCO_SPLIT_INC_0_ADDR=0.0.0.0
CISCO_SPLIT_INC_0_NETMSSK=0.0.0.0
CISCO_SPLIT_INC_0_NETMASKLEN=0

OpenConnect's standard vpnc-script takes care to handle this cases identically to that of INTERNAL_IP4_NETAMSK=0.0.0.0 (https://gitlab.com/openconnect/vpnc-scripts/blob/921e87609d98c2f03739bd7bce03a997857dd562/vpnc-script#L872-876), but nm-openconnect-service-openconnect-helper.c has been throwing out 0.0.0.0/0 "split" routes.

Evidence of this bug impacting users:

NetworkManager-openconnect should be modified to accept /0 routes (IPv4 or IPv6) if they arrive labeled as "split" routes, even though calling them "split" routes is clearly a misnomer in this case.

Signed-off-by: Daniel Lenski dlenski@gmail.com

Edited by Daniel Lenski

Merge request reports