[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Confirming is working again in 17.10 -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Confirmed Status in network-manager source package in Zesty: Confirmed Status in network-manager source package in Artful: Confirmed Bug description: [Impact] * NetworkManager incorrectly handles dns-priority of the VPN-like connections, which leads to leaking DNS queries outside of the VPN into the general internet. * Upstream has resolved this issue in master and 1.8 to correctly configure any dns backends with negative dns-priority settings. [Test Case] #FIXME# * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. #FIXME# [Regression Potential] * If this issue is changed DNS resolution will change, for certain queries, to go via VPN rather than general internet. And therefore, one may get new/different results or even loose access to resolve/access certain parts of the interent depending on what the DNS server on VPN chooses to respond to. [Other Info] * Original bug report I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1624317/+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
Re: [Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Hi! There is a fix submitted as a patch i. The thread I have been using for a while. Works flawlessly for me. -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 13. Sep 2017 14:55 by 1624...@bugs.launchpad.net: > Does anyone know if this happens to be fixed in 17.10? I have little > hope that the fix is ever going to make into 17.04... > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1624317 > > Title: > systemd-resolved breaks VPN with split-horizon DNS > > Status in NetworkManager: > Unknown > Status in network-manager package in Ubuntu: > Confirmed > Status in network-manager source package in Zesty: > Confirmed > Status in network-manager source package in Artful: > Confirmed > > Bug description: > [Impact] > >* NetworkManager incorrectly handles dns-priority of the VPN-like > connections, which leads to leaking DNS queries outside of the VPN > into the general internet. > >* Upstream has resolved this issue in master and 1.8 to correctly > configure any dns backends with negative dns-priority settings. > > [Test Case] > > #FIXME# > >* detailed instructions how to reproduce the bug > >* these should allow someone who is not familiar with the affected > package to reproduce the bug and verify that the updated package fixes > the problem. > > #FIXME# > > [Regression Potential] > >* If this issue is changed DNS resolution will change, for certain > queries, to go via VPN rather than general internet. And therefore, > one may get new/different results or even loose access to > resolve/access certain parts of the interent depending on what the DNS > server on VPN chooses to respond to. > > [Other Info] > >* Original bug report > > I use a VPN configured with network-manager-openconnect-gnome in which > a split-horizon DNS setup assigns different addresses to some names > inside the remote network than the addresses seen for those names from > outside the remote network. However, systemd-resolved often decides > to ignore the VPN’s DNS servers and use the local network’s DNS > servers to resolve names (whether in the remote domain or not), > breaking the split-horizon DNS. > > This related bug, reported by Lennart Poettering himself, was closed with > the current Fedora release at the time reaching EOL: > > https://bugzilla.redhat.com/show_bug.cgi?id=1151544 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/network-manager/+bug/1624317/+subscriptions -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Confirmed Status in network-manager source package in Zesty: Confirmed Status in network-manager source package in Artful: Confirmed Bug description: [Impact] * NetworkManager incorrectly handles dns-priority of the VPN-like connections, which leads to leaking DNS queries outside of the VPN into the general internet. * Upstream has resolved this issue in master and 1.8 to correctly configure any dns backends with negative dns-priority settings. [Test Case] #FIXME# * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. #FIXME# [Regression Potential] * If this issue is changed DNS resolution will change, for certain queries, to go via VPN rather than general internet. And therefore, one may get new/different results or even loose access to resolve/access certain parts of the interent depending on what the DNS server on VPN chooses to respond to. [Other Info] * Original bug report I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More
[Touch-packages] [Bug 1704422] Re: systemd-resolved keeps swapping DNS servers and breaking name resolution
Found out it's related to some occasional packet loss. Why this happens, I'm not sure, but appears to be more related to the wireless kernel mod than systemd in this case. ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/1704422 Title: systemd-resolved keeps swapping DNS servers and breaking name resolution Status in systemd package in Ubuntu: Invalid Bug description: Hi, I think the name is self explanatory, let me paste some logs of what does my syslog look like at any given time: https://paste.ubuntu.com/25089356/ Jul 14 16:49:23 Tuxedo systemd-resolved[1120]: Using system hostname 'Tuxedo'. Jul 14 16:49:52 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.8.8. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.4.4. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::8844. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.8.8. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.4.4. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 8.8.4.4. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::. Jul 14 16:50:19 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::8844. (...) Jul 14 16:50:43 Tuxedo systemd-resolved[1120]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 78.46.223.24. Jul 14 16:50:43 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:44 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:45 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:48 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:48 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:49 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:50 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:50 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. This happens both over the VPN and without (only than without the VPN I don't get the log messages, just a huge packet loss): tux@Tuxedo:~$ ping google.es ^T192PING google.es (216.58.201.131) 56(84) bytes of data. 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=1 ttl=55 time=26.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=5 ttl=55 time=19.5 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=9 ttl=55 time=24.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=10 ttl=55 time=22.3 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=14 ttl=55 time=20.5 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=20 ttl=55 time=20.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=22 ttl=55 time=26.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=24 ttl=55 time=29.2 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=25 ttl=55 time=20.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=26 ttl=55 time=22.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=27 ttl=55 time=21.0 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=28 ttl=55 time=30.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=29 ttl=55 time=23.2 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=30 ttl=55 time=29.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=37 ttl=55 time=30.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=40 ttl=55 time=24.8 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=43 ttl=55 time=23.3 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=45 ttl=55 time=22.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=46 ttl=55 time=21.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=53 ttl=55 time=23.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=61 ttl=55 time=21.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=62 ttl=55 time=19.3 ms ^C --- google.es ping
[Touch-packages] [Bug 1704422] Re: systemd-resolved keeps swapping DNS servers and breaking name resolution
Hi, The release is Ubuntu 17.10 -- 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/1704422 Title: systemd-resolved keeps swapping DNS servers and breaking name resolution Status in systemd package in Ubuntu: New Bug description: Hi, I think the name is self explanatory, let me paste some logs of what does my syslog look like at any given time: https://paste.ubuntu.com/25089356/ Jul 14 16:49:23 Tuxedo systemd-resolved[1120]: Using system hostname 'Tuxedo'. Jul 14 16:49:52 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.8.8. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.4.4. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::8844. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.8.8. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.4.4. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 8.8.4.4. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::. Jul 14 16:50:19 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::8844. (...) Jul 14 16:50:43 Tuxedo systemd-resolved[1120]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 78.46.223.24. Jul 14 16:50:43 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:44 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:45 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:48 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:48 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:49 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:50 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:50 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. This happens both over the VPN and without (only than without the VPN I don't get the log messages, just a huge packet loss): tux@Tuxedo:~$ ping google.es ^T192PING google.es (216.58.201.131) 56(84) bytes of data. 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=1 ttl=55 time=26.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=5 ttl=55 time=19.5 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=9 ttl=55 time=24.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=10 ttl=55 time=22.3 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=14 ttl=55 time=20.5 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=20 ttl=55 time=20.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=22 ttl=55 time=26.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=24 ttl=55 time=29.2 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=25 ttl=55 time=20.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=26 ttl=55 time=22.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=27 ttl=55 time=21.0 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=28 ttl=55 time=30.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=29 ttl=55 time=23.2 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=30 ttl=55 time=29.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=37 ttl=55 time=30.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=40 ttl=55 time=24.8 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=43 ttl=55 time=23.3 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=45 ttl=55 time=22.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=46 ttl=55 time=21.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=53 ttl=55 time=23.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=61 ttl=55 time=21.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=62 ttl=55 time=19.3 ms ^C --- google.es ping statistics --- 62 packets transmitted, 22 received, 64% packet loss, time 61869ms rtt min/avg/max/mdev = 19.394/23.851/30.417/3.404 ms Let me know if I can provide any other details. To manage
[Touch-packages] [Bug 1704422] [NEW] systemd-resolved keeps swapping DNS servers and breaking name resolution
Public bug reported: Hi, I think the name is self explanatory, let me paste some logs of what does my syslog look like at any given time: https://paste.ubuntu.com/25089356/ Jul 14 16:49:23 Tuxedo systemd-resolved[1120]: Using system hostname 'Tuxedo'. Jul 14 16:49:52 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.8.8. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.4.4. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::. Jul 14 16:50:17 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::8844. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.8.8. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 8.8.4.4. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 8.8.4.4. Jul 14 16:50:18 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::. Jul 14 16:50:19 Tuxedo systemd-resolved[1120]: Switching to fallback DNS server 2001:4860:4860::8844. (...) Jul 14 16:50:43 Tuxedo systemd-resolved[1120]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 78.46.223.24. Jul 14 16:50:43 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:44 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:45 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:48 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:48 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:49 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. Jul 14 16:50:50 Tuxedo systemd-resolved[1120]: Switching to DNS server 162.242.211.137 for interface tun0. Jul 14 16:50:50 Tuxedo systemd-resolved[1120]: Switching to DNS server 78.46.223.24 for interface tun0. This happens both over the VPN and without (only than without the VPN I don't get the log messages, just a huge packet loss): tux@Tuxedo:~$ ping google.es ^T192PING google.es (216.58.201.131) 56(84) bytes of data. 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=1 ttl=55 time=26.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=5 ttl=55 time=19.5 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=9 ttl=55 time=24.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=10 ttl=55 time=22.3 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=14 ttl=55 time=20.5 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=20 ttl=55 time=20.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=22 ttl=55 time=26.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=24 ttl=55 time=29.2 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=25 ttl=55 time=20.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=26 ttl=55 time=22.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=27 ttl=55 time=21.0 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=28 ttl=55 time=30.4 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=29 ttl=55 time=23.2 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=30 ttl=55 time=29.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=37 ttl=55 time=30.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=40 ttl=55 time=24.8 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=43 ttl=55 time=23.3 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=45 ttl=55 time=22.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=46 ttl=55 time=21.9 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=53 ttl=55 time=23.7 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=61 ttl=55 time=21.1 ms 64 bytes from mad06s25-in-f3.1e100.net (216.58.201.131): icmp_seq=62 ttl=55 time=19.3 ms ^C --- google.es ping statistics --- 62 packets transmitted, 22 received, 64% packet loss, time 61869ms rtt min/avg/max/mdev = 19.394/23.851/30.417/3.404 ms Let me know if I can provide any other details. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- 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/1704422 Title: systemd-resolved keeps swapping DNS servers and breaking name resolution Status in systemd package in Ubuntu: New Bug description: Hi, I think the name is self explanatory, let me paste some logs
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Hi Nicholas, I upgraded to 17.04, installed your patch and I can now say that dns leaks when using network-manager-openvpn + network-manager-openvpn-gnome are gone for good now. Awesome work, thanks. -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Hi! Thanks for the patch Nicholas. I will upgrade to 17.04, test it and report back tonight or tomorrow at most. -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1686254] Re: OpenVPN auto-connect options greyed out or missing for no reason
Not a bug. ** Changed in: openvpn (Ubuntu) Status: New => Invalid -- 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/1686254 Title: OpenVPN auto-connect options greyed out or missing for no reason Status in network-manager package in Ubuntu: Invalid Status in openvpn package in Ubuntu: Invalid Status in plasma-nm package in Ubuntu: Invalid Bug description: "Automatically connect to this network..." and "Automatically connect to VPN when..." are greyed out or missing from the GUI, the former is also "checked" however this is not true as it never attempts to auto connect. There's no reason for these to be unavailable, especially when personal encrypted passwords and keys are used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1686254/+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 1686254] Re: OpenVPN auto-connect options greyed out or missing for no reason
Not a bug. ** Changed in: plasma-nm (Ubuntu) Status: New => Invalid -- 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/1686254 Title: OpenVPN auto-connect options greyed out or missing for no reason Status in network-manager package in Ubuntu: Invalid Status in openvpn package in Ubuntu: Invalid Status in plasma-nm package in Ubuntu: Invalid Bug description: "Automatically connect to this network..." and "Automatically connect to VPN when..." are greyed out or missing from the GUI, the former is also "checked" however this is not true as it never attempts to auto connect. There's no reason for these to be unavailable, especially when personal encrypted passwords and keys are used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1686254/+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 1686254] Re: OpenVPN auto-connect options greyed out or missing for no reason
Not a bug. ** Changed in: network-manager (Ubuntu) Status: New => Invalid -- 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/1686254 Title: OpenVPN auto-connect options greyed out or missing for no reason Status in network-manager package in Ubuntu: Invalid Status in openvpn package in Ubuntu: Invalid Status in plasma-nm package in Ubuntu: Invalid Bug description: "Automatically connect to this network..." and "Automatically connect to VPN when..." are greyed out or missing from the GUI, the former is also "checked" however this is not true as it never attempts to auto connect. There's no reason for these to be unavailable, especially when personal encrypted passwords and keys are used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1686254/+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 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Hi, I have been posting quite a bit of information on bug https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1652525 As I didn't really realize there was this one open too, sorry. Maybe something is going to be useful for you. Cheers, J -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1686254] Re: OpenVPN auto-connect options greyed out or missing for no reason
Well, this is the official Ubuntu wiki: https://help.ubuntu.com/stable /ubuntu-help/net-vpn-connect.html In case you can think of any improvement to make it clearer I guess that the Documentation team will be more than happy to have a look at it. :) -- 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/1686254 Title: OpenVPN auto-connect options greyed out or missing for no reason Status in network-manager package in Ubuntu: New Status in openvpn package in Ubuntu: New Status in plasma-nm package in Ubuntu: New Bug description: "Automatically connect to this network..." and "Automatically connect to VPN when..." are greyed out or missing from the GUI, the former is also "checked" however this is not true as it never attempts to auto connect. There's no reason for these to be unavailable, especially when personal encrypted passwords and keys are used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1686254/+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 1686254] Re: OpenVPN auto-connect options greyed out or missing for no reason
** Tags removed: openvpn ** Tags added: gnome-network-manager -- 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/1686254 Title: OpenVPN auto-connect options greyed out or missing for no reason Status in network-manager package in Ubuntu: New Status in openvpn package in Ubuntu: New Status in plasma-nm package in Ubuntu: New Bug description: "Automatically connect to this network..." and "Automatically connect to VPN when..." are greyed out or missing from the GUI, the former is also "checked" however this is not true as it never attempts to auto connect. There's no reason for these to be unavailable, especially when personal encrypted passwords and keys are used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1686254/+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 1686254] Re: OpenVPN auto-connect options greyed out or missing for no reason
Hi, do you mean on the "Network connections" menu where you select the network connection to use? If it's correctly listed under "VPN" that you won't have the "automatically connect to this network at startup", you need to designate a real network interface that will be brought up on boot (like wired) and then select on that interface options to automatically connect to the VPN when brought up. The VPN is creating a virtual interface (tun0 usually) but it needs first that an actual interface is up and able to send/receive the packets for the TLS handshake (and the rest of the packets later too, actually), so it doesn't look like a bug to me ? Are you able to check those two options on any other network connection? -- 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/1686254 Title: OpenVPN auto-connect options greyed out or missing for no reason Status in network-manager package in Ubuntu: New Status in openvpn package in Ubuntu: New Status in plasma-nm package in Ubuntu: New Bug description: "Automatically connect to this network..." and "Automatically connect to VPN when..." are greyed out or missing from the GUI, the former is also "checked" however this is not true as it never attempts to auto connect. There's no reason for these to be unavailable, especially when personal encrypted passwords and keys are used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1686254/+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
