On Jun 4, 2017 3:33 PM, "Alexander Huynh" <alexander at cloudflare.com> wrote:
>I'm attaching a patch to fix a minor problem with IPv6 routes, wherein
>a /128 route advertised by the server will end up being processed as a
>default route on the client.
>
>Thanks for providing us with a nice AnyConnect alternative!
>
> diff --git a/vpnc-script b/vpnc-script
> index 6302987..3434ef6 100755
> Signed-off-by: Alexander Huynh <alex at frothy.coffee>
> --- a/vpnc-script
> +++ b/vpnc-script
> @@ -749,10 +749,10 @@ do_connect() {
> while [ $i -lt $CISCO_IPV6_SPLIT_INC ] ; do
> eval NETWORK="\${CISCO_IPV6_SPLIT_INC_${i}_ADDR}"
> eval NETMASKLEN="\${CISCO_IPV6_SPLIT_INC_${i}_MASKLEN}"
> - if [ $NETMASKLEN -lt 128 ]; then
> - set_ipv6_network_route "$NETWORK" "$NETMASKLEN"
> - else
> + if [ $NETMASKLEN -eq 0 ]; then
> set_ipv6_default_route
> + else
> + set_ipv6_network_route "$NETWORK" "$NETMASKLEN"
> fi
> i=`expr $i + 1`
> done
Looks good to me.
I wonder why the current vpnc-script has this behavior. It appears to
have been there since the original addition of IPv6 route support:
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/9f8c68c11a1f9f9a822e634459ce104f2bc44bb6
Is there some well-known case where a misconfigured server reports a
default IPv6 route as /128??
Dan
