Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • NetworkManager NetworkManager
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 222
    • Issues 222
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 22
    • Merge requests 22
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

We are currently migrating away from gitlab hosting cloud for the registry. There will be a final maintenance down time on Sunday 27th August, from approx 8-12am UTC. See the tracker issue for more informations. Note that the registry will see a brief outage, and potentially lag between uploads and availability during that window.

  • NetworkManagerNetworkManager
  • NetworkManagerNetworkManager
  • Issues
  • #405
Closed
Open
Issue created Apr 01, 2020 by Tore Anderson@toreanderson

wireguard: connection dns servers are not pushed to systemd-resolved

When I import a WireGuard config file that contains DNS servers, those DNS servers make it fine into the NetworkManager connection:

[:~] $ grep DNS /tmp/msvpn.conf
DNS = 87.238.33.1, 2a02:c0::1
[:~] $ nmcli con import type wireguard file /tmp/msvpn.conf
Connection 'msvpn' (fb2e91d6-83b6-4698-bf79-d7725c52fd99) successfully added.
[:~] $ nmcli con show msvpn | grep dns
connection.mdns:                        -1 (default)
ipv4.dns:                               87.238.33.1
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.ignore-auto-dns:                   no
ipv6.dns:                               2a02:c0::1
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.ignore-auto-dns:                   no

However, these DNS servers are for some reason not pushed to systemd-resolved:

[:~] 1 $ resolvectl status msvpn
Link 19 (msvpn)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

This in turn results in all DNS queries failing:

[:~] $ resolvectl query fud.no
fud.no: resolve call failed: All attempts to contact name servers or networks failed

Why? Because systemd-resolved falls back on using the ISP name servers through the tunnel. However, the ISP name servers refuse queries originating from outside their own network ranges, so that does not work:

[:~] 1 $ resolvectl status wwp0s20f0u3c3
Link 14 (wwp0s20f0u3c3)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes
  Current DNS Server: 193.213.112.4
         DNS Servers: 193.213.112.4
                      130.67.15.198
                      2001:4600:4:fff::52
                      2001:4600:4:1fff::52
          DNS Domain: ~.
[:~] $ sudo tcpdump -ni msvpn port 53 -c 10
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on msvpn, link-type RAW (Raw IP), capture size 262144 bytes
22:52:17.764631 IP 100.64.255.1.48768 > 193.213.112.4.domain: 25374+% [1au] AAAA? push.services.mozilla.com.fud.no. (84)
22:52:17.818677 IP 193.213.112.4.domain > 100.64.255.1.33145: 45171 Refused- 0/0/1 (65)
22:52:17.819202 IP 100.64.255.1.53130 > 130.67.15.198.domain: 45171+% [1au] A? mattermost.redpill-linpro.com.fud.no. (88)
22:52:17.821672 IP6 2001:4600:4:1fff::52.domain > 2a02:c0:2:7::1.54603: 38306 Refused- 0/0/1 (65)
22:52:17.822093 IP6 2a02:c0:2:7::1.51177 > 2001:4600:4:fff::52.domain: 38306+% [1au] AAAA? mattermost.redpill-linpro.com.fud.no. (65)
22:52:17.850780 IP 130.67.15.198.domain > 100.64.255.1.60774: 29748 Refused- 0/0/1 (64)
22:52:17.851383 IP6 2a02:c0:2:7::1.42169 > 2001:4600:4:1fff::52.domain: 29748+% [1au] A? nextcloud.redpill-linpro.com.fud.no. (87)
22:52:17.864001 IP6 2001:4600:4:fff::52.domain > 2a02:c0:2:7::1.41029: 7609 Refused- 0/0/1 (64)
22:52:17.865206 IP 100.64.255.1.48384 > 193.213.112.4.domain: 7609+% [1au] AAAA? nextcloud.redpill-linpro.com.fud.no. (87)
22:52:17.872557 IP6 2001:4600:4:1fff::52.domain > 2a02:c0:2:7::1.48567: 11409 Refused- 0/0/1 (61)
10 packets captured
11 packets received by filter
0 packets dropped by kernel

I'm using Fedora 31; NetworkManager-1.20.10-1.fc31.x86_64.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking