Wireguard client not working even if wg0 is showing traffic count

Ask Fedora Ask in English
,
1

Hi,

I just tried experimenting with wireguard. I have successfully set up my opnsense wireguard and one android client. It works perfectly as default gw to all traffic.

Now I added f36 as client. I used network manager gui to create the tunnel according to instructions here: gui-guide

I get the tunnel up, looking from sudo wg I can see packets are moving. Also from the server end.

╰─$ sudo wg          
interface: wg0
  public key:  (hidden)
  private key: (hidden)
  listening port: 52412
  fwmark: 0xcadd

peer:  (hidden)
  endpoint: (hidden):55555
  allowed ips: 0.0.0.0/0
  latest handshake: 11 seconds ago
  transfer: 8.98 KiB received, 1.68 GiB sent

However none of the traffic I try to create works. No ping, no web surfing. I see it’s correctly set up as default gw, but still. What coud I miss?

╰─$ ip r s             
default via 192.168.116.1 dev wg0 proto static metric 50 
default via 192.168.21.99 dev wlp2s0 proto dhcp src 192.168.21.29 metric 20600 
192.168.21.0/24 dev wlp2s0 proto kernel scope link src 192.168.21.29 metric 600 
192.168.116.0/24 dev wg0 proto kernel scope link src 192.168.116.21 metric 50

My opnsense wg server has wg address 192.168.116.1/24, and the DNS is behind it in LAN address 192.168.117.1. See config from f36 client here:

===============================================================================
                      Connection profile details (pilivi)
===============================================================================
connection.id:                          home
connection.uuid:                        47feddae-77ad-4edf-8cbf-fb53c49d28b9
connection.stable-id:                   --
connection.type:                        wireguard
connection.interface-name:              wg0
connection.autoconnect:                 no
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:                   1658735388
connection.read-only:                   no
connection.permissions:                 --
connection.zone:                        --
connection.master:                      --
connection.slave-type:                  --
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
connection.dns-over-tls:                -1 (default)
connection.wait-device-timeout:         -1
-------------------------------------------------------------------------------
ipv4.method:                            manual
ipv4.dns:                               192.168.117.1
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         192.168.116.21/24
ipv4.gateway:                           192.168.116.1
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.required-timeout:                  -1 (default)
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-reject-servers:               --
-------------------------------------------------------------------------------
ipv6.method:                            ignore
-------------------------------------------------------------------------------
wireguard.private-key:                  <hidden>
wireguard.private-key-flags:            0 (none)
wireguard.listen-port:                  0
wireguard.fwmark:                       0x0
wireguard.peer-routes:                  yes
wireguard.mtu:                          0
wireguard.ip4-auto-default-route:       -1 (default)
wireguard.ip6-auto-default-route:       -1 (default)
-------------------------------------------------------------------------------
proxy.method:                           none
proxy.browser-only:                     no
proxy.pac-url:                          --
proxy.pac-script:                       --
-------------------------------------------------------------------------------

The allowed routes in nm configurator is set to 0.0.0.0/0, so it would become the default gw.

While connection is up, it looks like this:

╰─$ nmcli d show wg0   
GENERAL.DEVICE:                         wg0
GENERAL.TYPE:                           wireguard
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1420
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     home
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/18
IP4.ADDRESS[1]:                         192.168.116.21/24
IP4.GATEWAY:                            192.168.116.1
IP4.ROUTE[1]:                           dst = 192.168.116.0/24, nh = 0.0.0.0, mt = 50
IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 0.0.0.0, mt = 50, table=51933
IP4.ROUTE[3]:                           dst = 0.0.0.0/0, nh = 192.168.116.1, mt = 50
IP4.DNS[1]:                             192.168.117.1
IP6.ADDRESS[1]:                         fe80::31a2:e334:cf60:5127/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 256

Any ideas what is missing?

1 Like
2

I had issues like this before I started using wg-quick to configure the interface.

fedora has a systemd service to start/stop a wg-quick-managed interface. It ensures that fwmark is used to route traffic correctly. When you have multiple default routes (even with correct metric) it can cause problems.

I start the wg-quick@wg0 service through the usual systemd enabling mechanism and use the Wireguard Indicator extension in GNOME to permit selection, and disabling/re-enabling, of the interface.

2 Likes
3

Thanks, the wq-quick worked fine. Then I started it using the systemd, which also brought the if up, but it lost DNS. Ping with IPs work allright, but now I don’t get DNS right even if restarting systemd-resolved. Seems rahter flaky.

I have this:

╰─$ sudo cat /etc/wireguard/wg0.conf  
[Interface]
Address = 192.168.116.21/32
SaveConfig = true
ListenPort = 51392
FwMark = 0xca6c
PrivateKey = (hidden)
DNS = 192.168.117.1

And using the systemd way it seems to drop the DNS line for some reason after down event. So for the next up there is no DNS.

4

actually the both down scripts remove the DNS line. Perhaps I need to drop the SaveConfig, I don’t know what good does it do.

5

Yes, I don’t have SaveConfig and FwMark in the [Interface] part.

ip rule show should give you something like:

Blockquote
[neil@vivobook ~]$ ip rule show
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c lookup 51820
32766: from all lookup main
32767: from all lookup default

That’s the magic which makes routing work.

1 Like
6

wg-quick is a script, and in the saveconfig routine it calls “resolvconf -l wg0” to get the nameservers assigned to wg0. However, the “-l” switch is not supported in Fedora and the DNS option gets lost.
So the wg-quick script needs some polishing.
If you do not change wg0 config during runtime, just leave away the saveconfig.

As far I can see, the wg-quick service is just calling wg-quick, so there should not be any difference.

1 Like
7

The saveconfig functionality would be problematical. I don’t use that functionality and DNS servers are read from /etc/wireguard/wg0.conf. resolvectl status confirms that those DNS servers are being used on wg0.

8

It works with an one-line patch of wg-quick, using the command:
“resolvectl dns wg0”.
A pipe to “cut -d: -f2-” strips off the interface name, leaving the list of DNS servers.
Next piped to awk which prints the fields prepended with “nameserver” and “\n” appended. Then it’s interpreted by the code trying to interpret the not supported “resolvconf -l wg0”
Unfortunately, I am not allowed to upload the patch file and not sure whether it survives blockquote.

1 Like
9

Is there bug opened already about this? If you know a fix, and are willing, couldn’t you fork it, branch, commit fix and do pull request for a fix? If there is no bugzilla issue, I can create it.

10

Actually, there are two separate issues here. The one that dns is not handled properly, and the other that netork manger doesn’t function properly. I started this with nm So two issues should be done. I will check and create them at some point if there isn’t issues yet.

11

Yes, you are right. Concerning nm: in my situation it works as expected, so no problem here. Concerning the DNS: my fix is correct in the sense that the existing code is not affected and should stay working, but I better want to leave it to a professional grade programmer to correctly implement support for the different distributions… I will create an bugzilla entry and report my findings.

https://bugzilla.redhat.com/show_bug.cgi?id=2111343

1 Like
12

I see. The development model is kernelish. It seems there is no issue tracker for wireguard-tools, but mailing list. So I’ll post there about wg-quick for a discussion.

13

Hi @ikke For some back ground info Understanding modern Linux routing (and wg-quick)

1 Like
14

I believe this situation has arisen because fedora is using resolvectl to implement a subset of resolvconf functionality - there are a number of unsupported resolvconf command line flags which likely won’t be implemented.

Whether the wireguard-tools developers will want to support this special case is another matter. My understanding of the saveconfig option is that it permits the state of a manually configured WireGuard link to be written to a config file. I’m not sure that it actually serves much usefulness inside an existing configuration file. If you want to dynamically reconfigure your configuration file then maybe it could be useful but it’s not a typical usecase.

We should be aware that DNS entries configured in a WireGuard configuration file, without the saveconfig option in there, will be picked-up and used correctly.

15

Yes, I agree, no need at all for the save config in this kinda road warrior/static setup. I picked it up from some example at my very first try, just because of my ignorance on the topic.

I will also retry the network manager at some point on fedora. In a meanwhile I’ve been setting up some remote home automation raspi boxes (raspios) and wg has been working fluently, and I’ve learned more. Super nice tool to setup vpn!

16

The NetworkManager Settings Tools in GNOME don’t support WireGuard VPNs (it’s been asked for) so you either have to manually create your NetworkManager configuration file or use wg-quick and the Wireguard Indicator GNOME Shell extension as I do.

17

nm-connection-editor does support it, it only puts Wireguard between the virtual interfaces, not the VPN’s.

18

The original profile sets ipv4.gateway. That is not right.

ipv4.gateway basically means to add a default route to the main table. If you want to route all traffic via the VPN (with allowed-ips=0.0.0.0/0), you must make sure that there is no routing loop. Setting the gateway does just that. Instead, let NetworkManager handle that automatically (via wireguard.ip4-auto-default-route).

All you need is nmcli connection modify "home" ipv4.gateway '' and reactivate the profile with nmcli connection up home.

– Update: man nm-settings also comments about that. See wireguard.ip4-auto-default-route.

19

@thaller thanks! This made it work. Obvious now that you point it out. So two things it required:

nmcli connection modify "home" ipv4.gateway ''"
nmcli connection modify "home" wireguard.ip4-auto-default-route 1

The first one wasn’t enough, as by default the wireguard route setting was off:

wireguard.ip4-auto-default-route:       -1 (default)

man page doesn’t say what’s good option for it, but just by luck “1” made it true.

Anyhow, thanks, now both the wg-quick and nmcli do work, great!

20

@hmmsjan Thanks, I verified your patch work on my laptop.