Your message dated Sat, 04 Apr 2020 16:34:45 +0100
with message-id <[email protected]>
and subject line Re: vpnc-scripts: vpnc-script ignores netmask in VPN-provided
routes
has caused the Debian Bug report #940264,
regarding vpnc-scripts: vpnc-script ignores netmask in VPN-provided routes
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
940264: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940264
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: vpnc-scripts
Version: 0.1~git20190117-1
Severity: normal
Dear Maintainer,
When VPN server (Cisco in my case) provides a list of sub-nets that should not
be routed through VPN, the script creates a bunch of corresponding routes but
omits the provided netmasks, thus effectively ignoring the feature. Moreover,
on termination of VPN connection the script is not able to properly remove
created routes because they use invalid netmask (/32 by default).
I traced the problem down to the 'route add' command executed inside
set_exclude_route(). The following hack fixes the issue for me:
cmd="$IPROUTE route add `$IPROUTE route get "$NETWORK/$NETMASKLEN"
| fix_ip_get_output`"
cmd=`echo $cmd | sed -e 's@ via @'"/$NETMASKLEN via @"` # add proper netmask
$cmd
(A similar change is needed for set_ipv6_exclude_route() if you use IPv6.)
I noticed the issue after upgrade from Stretch to Buster. I don't know whether
it worked before, or just was not supported, and whether it could be caused by
a potential change in 'ip route get' output format or not.
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages vpnc-scripts depends on:
ii iproute2 4.20.0-2
ii net-tools 1.60+git20180626.aebd88e-1
vpnc-scripts recommends no packages.
Versions of packages vpnc-scripts suggests:
pn dnsmasq <none>
ii openssh-server 1:7.9p1-10
pn resolvconf <none>
-- no debconf information
--
...Bye..Dmitry.
--- End Message ---
--- Begin Message ---
Control: fixed -1 0.1~git20200226-1
On Thu, 26 Mar 2020 15:55:54 +0100 =?UTF-8?Q?Stefan_B=c3=bchler?= <
[email protected]> wrote:
> Hi,
>
> On Sat, 14 Sep 2019 23:00:42 +0300 Dmitry Semyonov <[email protected]
> wrote:
> > Package: vpnc-scripts
> > Version: 0.1~git20190117-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > When VPN server (Cisco in my case) provides a list of sub-nets that
should not
> > be routed through VPN, the script creates a bunch of corresponding
routes but
> > omits the provided netmasks, thus effectively ignoring the feature.
Moreover,
> > on termination of VPN connection the script is not able to properly
remove
> > created routes because they use invalid netmask (/32 by default).
> >
> > I traced the problem down to the 'route add' command executed
inside
> > set_exclude_route(). The following hack fixes the issue for me:
> >
> > cmd="$IPROUTE route add `$IPROUTE route get
"$NETWORK/$NETMASKLEN"
> > | fix_ip_get_output`"
> > cmd=`echo $cmd | sed -e 's@ via @'"/$NETMASKLEN via @"` # add
proper netmask
> > $cmd
> >
> > (A similar change is needed for set_ipv6_exclude_route() if you use
IPv6.)
>
> This has been fixed upstream:
> -
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/fe5cb8a6d9791aa5217db31825b66eb185066a8d
> - cleanup:
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/0851a20770d875d5b6cb76ec49b3137f56410f9a
>
> Any chance this could end up in a stable update?
>
> cheers,
> Stefan
Fixed as part of the upload of the latest upstream version
0.1~git20200226-1.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
--- End Message ---
