It says. In particular, on the most recent (yet unreleased) version of man nm-settings:
Note that for this automatism to work, you usually don’t want to set ipv4.gateway, because that will result in a conflicting default route.
Leaving this at the default will enable this option automatically if ipv4.never-default is not set and there are any peers that use a default-route as allowed-ips. Since this automatism only makes sense if you also have a peer with an /0 allowed-ips, it is usually not necessary to enable this explicitly. However, you can disable it if you want to configure your own routing and rules.
So, sure, explicitly settings wireguard.ip4-auto-default-route=1 works too. But it’s usually not useful.
In this case manual says by default it is in automatical mode, and from command line it says default -1. But like said, manual should state it so one should not be guessing. It could have what ever purposes in theory. However, I think command line said true once I set it to 1.
Just because I want to understand what’s going on, and because I cannot reproduce the problem. Client accepts 0.0.0.0/0
A gateway defined in the Wireguard IPv4 settings defines a default route to the wireguard endpoint with metric 50. The router pushed one via DHCP with metric 600, so wireguard wins and the system acts as desired.
“Add peer routes” does policy based routing and adds a fwmark. All packets containing this fwmark are directed to wg0. Because wg0 is a point-to-point interface, packets arrive in both cases just at the other end of the virtual line. The system acts as desired.
So… Why did it not work?
I can revert my config and reproduce it while hands on that laptop at some,e point. Not tonight. I also wonder what was the difference between our setups.
wg command showed packet counts, so tunnel was up. Some routing problem, that got fixed by the default option change. I need to recheck my nm settings, specificly 0.0.0.0/0 being only in allowed ips in wg1.conf.
With WireGuard, each peer needs to have subnets that are reachable via that peer. The “allowed-ips”. NetworkManager will automatically add routes to those subnets, unless wireguard.peer-routes is disabled. This importance of the allowed-ips is specific to WireGuard, and it calls this “cryptokey routing”.
In general, with IP tunnels of any kind, you must avoid that the underlay networks get routed via the tunnel itself. The challenges and possibilities are detailed here. That especially becomes relevant, if one of the allowed-ips is 0.0.0.0/0 or ::/0.
In that case, wg-quick and NetworkManager will configure policy routing, as explained here. In NetworkManager, wireguard.ip4-auto-default-route=no can be used to disable this automatism – in which case, you could configure your own routing setup in any way you want.
If you then configure also a default route in the main table for the WireGuard interface (which is what ipv4.gateway means), then that route will cause that the external IP addresses of the peers are routed via the tunnel itself. That’s doesn’t work.
You cannot configure routes that act based on the fwmark. However, you can configure routing rules (policy routing). And that is what NetworkManager and wg-quick does. If you check the routing tables and the rules, it will become clear that the default route works badly.
Thanks a lot! Now I understand. The default route is directed to wg0, which encrypts, marks the packet, and sent it to the endpoint. But the highest priority default route to the endpoint is wg0. Thight loop created. But I have a special case: my endpoint is on the same subnet, so the encrypted packet escapes by not using the default route!
I should have been using my external IP address + port forwarding to mimic the real life setup.