[Touch-packages] [Bug 1851407] Re: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

2019-11-14 Thread Joe Hohertz
I can possibly try 19.10 later, however at the moment I only have my LTS
laptop to test with.

Just to ensure we've covered any variations, here is a redacted version
of my connection file, in case I have missed anything.

[connection]
id=Vxxx
uuid=----
type=vpn
permissions=user::;
timestamp=1572967683

[vpn]
auth=SHA512
ca=/home//.cert/nm-openvpn/xxx-ca.pem
cert=/home//.cert/nm-openvpn/xxx-cert.pem
cert-pass-flags=0
cipher=AES-256-CBC
comp-lzo=adaptive
connection-type=password-tls
dev=tun
key=/home//.cert/nm-openvpn/xxx-key.pem
password-flags=2
remote=1.vpn..xxx
remote-cert-tls=server
reneg-seconds=604800
ta=/home//.cert/nm-openvpn/xxx-tls-auth.pem
ta-dir=1
username=xx
service-type=org.freedesktop.NetworkManager.openvpn

[ipv4]
dns-priority=50
dns-search=
method=auto
never-default=true

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1851407

Title:
  NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby
  a VPN connection which sets it's dns-priority to a negative value,
  which should cause the DNS server supplied by the DNS connection to be
  placed first, instead now refuses to place the DNS server into the
  resolver under any circumstance.

  Pinning the 1.10.6-2ubuntu1.1 works around the issue.

  I suspect the fix-dns-leak-lp1754671.patch has caused this regression.

  This patch should be reverted as soon as possible to restore proper
  functionality of network manager with respect to VPN servers with DNS
  resolvers.

  $ lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1851407] Re: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

2019-11-13 Thread Joe Hohertz
Did you ensure that the connection was set for "use only for resources
on the connection"? (I believe this may be ipv4.never-default=yes
setting in nmcli... and only bring it up because you do not mention it.)

I also think the negative DNS priority might be historical, no longer
needed. (I just noticed mine was set to 50, which I believe is default
for VPN connections now)

I should also note that if the never-default is set to "no"... I *will*
see the DNS server, however the routing is then incorrect as the VPN
concerned doesn't provide public routes.

So to be clear... never-default needs to be set to yes... DNS we expect
is from DHCP options sent from the VPN server, and the problem is that
you will see NO DNS servers for tun0 when you run the 'systemd-resolve
--status' command

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1851407

Title:
  NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby
  a VPN connection which sets it's dns-priority to a negative value,
  which should cause the DNS server supplied by the DNS connection to be
  placed first, instead now refuses to place the DNS server into the
  resolver under any circumstance.

  Pinning the 1.10.6-2ubuntu1.1 works around the issue.

  I suspect the fix-dns-leak-lp1754671.patch has caused this regression.

  This patch should be reverted as soon as possible to restore proper
  functionality of network manager with respect to VPN servers with DNS
  resolvers.

  $ lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1851407] Re: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

2019-11-12 Thread Joe Hohertz
1) Add an openvpn connection, which emits DHCP DNS servers, and is flagged "use 
only for resources on this connection"
2) Add a negative dns_priority to the connection via CLI or editing the 
connection

Prior to the change, this worked fine, you could connect, and the
indicated DNS server would become prioritised.

After the change, this no longer works, and networkmanager will not
associate a DNS server to the connection at all.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1851407

Title:
  NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby
  a VPN connection which sets it's dns-priority to a negative value,
  which should cause the DNS server supplied by the DNS connection to be
  placed first, instead now refuses to place the DNS server into the
  resolver under any circumstance.

  Pinning the 1.10.6-2ubuntu1.1 works around the issue.

  I suspect the fix-dns-leak-lp1754671.patch has caused this regression.

  This patch should be reverted as soon as possible to restore proper
  functionality of network manager with respect to VPN servers with DNS
  resolvers.

  $ lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1851407] [NEW] NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

2019-11-05 Thread Joe Hohertz
Public bug reported:

NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby a
VPN connection which sets it's dns-priority to a negative value, which
should cause the DNS server supplied by the DNS connection to be placed
first, instead now refuses to place the DNS server into the resolver
under any circumstance.

Pinning the 1.10.6-2ubuntu1.1 works around the issue.

I suspect the fix-dns-leak-lp1754671.patch has caused this regression.

This patch should be reverted as soon as possible to restore proper
functionality of network manager with respect to VPN servers with DNS
resolvers.

$ lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1851407

Title:
  NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

Status in network-manager package in Ubuntu:
  New

Bug description:
  NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby
  a VPN connection which sets it's dns-priority to a negative value,
  which should cause the DNS server supplied by the DNS connection to be
  placed first, instead now refuses to place the DNS server into the
  resolver under any circumstance.

  Pinning the 1.10.6-2ubuntu1.1 works around the issue.

  I suspect the fix-dns-leak-lp1754671.patch has caused this regression.

  This patch should be reverted as soon as possible to restore proper
  functionality of network manager with respect to VPN servers with DNS
  resolvers.

  $ lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression

2019-11-05 Thread Joe Hohertz
1.10.6-2ubuntu1.2 has cause a regression in functionality.

Anyone using a "split" VPN, where there is no default route, AND wish to
have DNS services supplied by the server to be honoured, via use of the
ipv4.dns-priority parameter, will have this broken. This is a bit of a
sore point considering the hoops one has to jump through to make this
work at all.

Reverting to previous version restores functionality.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1754671

Title:
  Full-tunnel VPN DNS leakage regression

Status in NetworkManager:
  Confirmed
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Invalid
Status in network-manager source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in network-manager source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  When using a VPN the DNS requests might still be sent to a DNS server outside 
the VPN when they should not

  [Test case]
  1) Set up a VPN with split tunneling:
a) Configure VPN normally (set up remote host, any ports and options needed 
for the VPN to work)
b) Under the IPv4 tab: enable "Use this connection only for the resources 
on its network".
c) Under the IPv6 tab: enable "Use this connection only for the resources 
on its network".

  2) Connect to the VPN.

  3) Run 'systemd-resolve --status'; note the DNS servers configured:
a) For the VPN; under a separate link (probably tun0), note down the IP of 
the DNS server(s). Also note the name of the interface (link).
b) For the "main" connection; under the link for your ethernet or wireless 
devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). 
Also note the name of the interface (link).

  4) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  5) In a separate terminal, run 'sudo tcpdump -ni 
  port 53'; let it run.

  6) In yet another terminal, issue name resolution requests using dig:
a) For a name known to be reachable via the public network:
   'dig www.yahoo.com'
b) For a name known to be reachable only via the VPN:
   'dig '

  7) Check the output of each terminal running tcpdump. When requesting
  the public name, traffic can go through either. When requesting the
  "private" name (behind the VPN), traffic should only be going through
  the interface for the VPN. Additionally, ensure the IP receiving the
  requests for the VPN name is indeed the IP address noted above for the
  VPN's DNS server.

  If you see no traffic showing in tcpdump output when requesting a
  name, it may be because it is cached by systemd-resolved. Use a
  different name you have not tried before.

  
  [Regression potential]
  The code change the handling of DNS servers when using a VPN, we should check 
that name resolution still work whne using a VPN in different configurations

  -

  In 16.04 the NetworkManager package used to carry this patch:
  
http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch

  It fixed the DNS setup so that when I'm on the VPN, I am not sending
  unencrypted DNS queries to the (potentially hostile) local
  nameservers.

  This patch disappeared in an update. I think it was present in
  1.2.2-0ubuntu0.16.04.4 but was dropped some time later.

  This security bug exists upstream too: 
https://bugzilla.gnome.org/show_bug.cgi?id=746422
  It's not a *regression* there though, as they didn't fix it yet 
(unfortunately!)

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1469346] [NEW] DHCPv6 responses with multiple addresses applied incorrectly to interface

2015-06-26 Thread Joe Hohertz
Public bug reported:

A DHCPv6 server may respond with multiple addresses, and is not an
unusual case as you may wish to provide both a ULA and a global prefix
to a common suffix. Recent versions of OpenWRT behave in this manner for
DHCPv6.

Network Manager is handling this *almost* correctly. Both addresses get
applied, just not simultaneously as would be expected.

The dhclient process is seeing both addresses, and both get processed by
the handler, but is handled as though there were two seperate requests,
applies the first address, promptly removes it, and replaces it with the
second address, resulting in only the latter address persisting after
interface setup.

After adding the following to the upstart config for network manager,
you can easily follow the mishandling of the response:

--log-level=debug --log-domains=DEVICE,IP6,DHCP6

The following are key lines from the debug logging:

Jun 20 23:21:16 pinky-linux NetworkManager[6244]: debug [1434856876.790352] 
[nm-system.c:280] sync_addresses(): (wlan0): adding address 
'2607:::ad10::61/128'
...

Jun 20 23:21:17 pinky-linux NetworkManager[6244]: debug [1434856877.837130] 
[nm-system.c:247] sync_addresses(): (wlan0): removing address 
'2607:::ad10::61/128'
Jun 20 23:21:17 pinky-linux NetworkManager[6244]: debug [1434856877.837526] 
[nm-system.c:280] sync_addresses(): (wlan0): adding address 
'fd5b:::10::61/128'

In this case the global prefixed address was applied, then immediately
replaced by the ULA prefixed one.

So it's correctly parsing both addresses of the response as supplied by
dhclient, but the end result is not what is expected for the given
configuration sent from the server.

The correct behaviour is to add/replace all addresses in the response as
a set.

This negates much of the usefulness of supporting DHCPv6, and is an
impediment to integration with IPv6 networks requiring it's use.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: network-manager 0.9.8.8-0ubuntu7.1
ProcVersionSignature: Ubuntu 3.16.0-38.52~14.04.1-generic 3.16.7-ckt10
Uname: Linux 3.16.0-38-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Jun 26 22:19:20 2015
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2015-05-21 (36 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS Trusty Tahr - Release amd64 (20150218.1)
IpRoute:
 default via 192.168.169.1 dev wlan0  proto static 
 192.168.169.0/24 dev wlan0  proto kernel  scope link  src 192.168.169.61  
metric 9
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=set
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.NetworkManager.NetworkManager.conf: 
2015-06-17T17:39:57.347300
mtime.conffile..etc.init.network.manager.conf: 2015-06-20T23:20:39.172713
nmcli-con:
 NAME  UUID   TYPE  
TIMESTAMPTIMESTAMP-REAL AUTOCONNECT   READONLY   
DBUS-PATH 
 somewhere 1bc6a70d-cf1a-4109-8a21-71656d34685c   
802-11-wireless   1435371500   Fri 26 Jun 2015 10:18:20 PM EDTyes   
no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE  STATE DBUS-PATH   
   
 eth0   802-3-ethernetunavailable   
/org/freedesktop/NetworkManager/Devices/1  
 wlan0  802-11-wireless   connected 
/org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSIONSTATE   NET-ENABLED   WIFI-HARDWARE   WIFI  
 WWAN-HARDWARE   WWAN  
 running 0.9.8.8connected   enabled   enabled 
enabledenabled enabled

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1469346

Title:
  DHCPv6 responses with multiple addresses applied incorrectly to
  interface

Status in network-manager package in Ubuntu:
  New

Bug description:
  A DHCPv6 server may respond with multiple addresses, and is not an
  unusual case as you may wish to provide both a ULA and a global prefix
  to a common suffix. Recent versions of OpenWRT behave in this manner
  for DHCPv6.

  Network Manager is handling this *almost* correctly. Both addresses
  get applied, just not simultaneously as would be expected.

  The dhclient process is seeing both addresses, and both get processed
  by the handler, but is handled as though there were two seperate
  requests, applies the first