Talk:WireGuard

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 08:20, 7 September 2026 (UTC)
:: Your reply ~~~~

Definitions

Anyone can point me to the technical description of site-to-point and site-to-site connections? I have never heard of site-to-point connections, and site-to-site connections. Point-to-point is a networking term, point-to-multipoint is a networking term too. Hub and spoke is a networking term. But what is a site-to-site connection? This both terms I am referring to are used in the first sentences on this article. Thanks Needle (talk) 12:02, 30 December 2020 (UTC)

Hi Needle, I'm no VPN or network expert, but does this help? --Maffblaster (talk) 18:08, 31 December 2020 (UTC)

I believe that a "site-to-point" connection is what is also called a "client-to-site" connection, i.e. a connection in which one VPN endpoint, the "client", is a single device (e.g. a laptop computer) and the other one is a gateway to a network of devices, giving the "client" secure access to the entire network. A "site-to-site" connection is a connection in which both VPN endpoints are gateways to networks, enabling secure communications between any pair of devices from those "sites". — GuillermoDH (talk) 21:03, 2 January 2021 (UTC)

Thanks. This all VPN jargon is kind of buzzword bingo for me, and most probably for the future readers too. I am not sure it makes sense mentioning, these 3 terms right at the beginning of the article. The reason is, this 3 connection types mentioned are possible with all kind of IPSec software. It is not exclusive to wireguard, actually even using openvpn, openconnect and vpnc. From my point of view these 3 connection types should be further explained in the article and and howto implement them. For example, as seen from the IP level, a "site-to-site" connection implementation is the same as "point-to-point", it only differs by the amount of IP routes on both sides, and the used routed protocol static routing or dynamic routing protocol. "site-to-point connection" might be maybe a term from the security area. I have been asking around on freenode in the known networking channels if "site-to-point" is actually a term that means something technical , and we all came to the same conclusion, this is marketing buzzword. I have swapped these 3 terms with "secure connections" Mentioning "full tunnel" or "split tunnel" conneciton would make more sense, not only here but also on other wiki articles. I might be biased, and have very limited knowledge about the security networking. I suggest to remove these 3 connection types if they are not explicitelly described in the article. Instead I would write "secure connections". Because then the article is more understandable for users and does not add any buzzword that are not eplained. I am not against mentioning these terms, I am more against it using "difficult to explain" terms that are not explained anymore. If someone would explain and howto implement I am for it. But as long as it is not found anywhere then I am a friend of simplicity. From my point of view, less is more. Needle (talk) 18:59, 3 January 2021 (UTC)

wg0.conf?

as a point of feedback, got here trying to set up wireguard and this completely glosses over how to write wg0.conf and I have no idea how to proceed. including instructions or linking to them would be incredibly helpful Witchyanna (talk) 16:46, 2 August 2022 (UTC)

I have taken the time to add more on the information you are requesting. See Special:Diff/1075103/1080553. --Maffblaster (talk) 21:37, 2 August 2022 (UTC)

WireGuard setup for netifrc does not work

To put simply, the instructions for setting up WireGuard (WG) via netifrc are incomplete and do not work.

Part 1 of problem:

In the "postup()" function, an nft command is ran to update the firewall; the issue is that the default rule set for nftables is an empty file located at /var/lib/nftables/rules-save. The nft command tries to add a rule to a chain named "output" in a table named "filter"; neither of which exist if the user simply emerged net-firewall/nftables manually or it got pulled in as a dependency. The solution I found was to copy-paste the "Typical workstation (combined IPv4 and IPv6)" from the Nftables/Examples wiki page into /var/lib/nftables/rules-save and edit the nft command to "nft insert rule inet filter ..." instead of "nft insert rule ip filter ..." so that it works for IPv4 and IPv6. I will probably add this to the wiki myself soon.

Part 2 of problem:

The "postup()" function does not actually route packets to the WG interface. I tested this with my home network and cannot get any packets to/from my router; I know the setup works because when I tested WG using "wg-quick", it works. When trying to use the netifrc method, the WG tunnel is established, but that's it -- no internet. On my router, I see that the WG tunnel is connected, but again -- no internet. I then commented out the nft command in "postup()" to see if that was the issue -- it was not. Commenting out the nft command resulted in internet, but my router stated that no packets were going through the WG tunnel. The "wg set wg0 ...", "ip route add ...", and the "ip rule add ..." commands are not routing the packets to the wg0 interface.

I tried looking at the "wg-quick" bash script to see how it makes WG work, but I don't know enough about "ip" nor "nft" to translate it.

FlyingBullets (talk) 13:39, 20 August 2024 (UTC)

I can confirm that example doesn't work. I tried that set up about a year ago and figured out wg-quick is a better solution. I'm not sure the rule 'nft insert rule ip filter output oifname!="wg0" mark!=334455 fib daddr type!=local counter reject || exit 1' makes sense. I suspect the 'official' method using 'ip rule add table main suppress_prefixlength 0' would work better, but I'm to lazy to test it. Finoderi (talk) 14:43, 20 August 2024 (UTC)

Update 1: I tried to copy some of the nft commands from the wg-quick script, specifically the "meta l4proto udp meta set ..." and "meta l4proto udp meta mark 334455 ..." (I inserted the 334455) -- it still does not work. I don't understand how wg-quick does it even after reading the commands; the commands in the "postup()" function make more sense, yet they don't work... FlyingBullets (talk) 15:48, 20 August 2024 (UTC)

It seems the example /etc/conf.d/net provided takes into account that we should already have a working nftables configuration with the needed kernel config and with the table and chain already configured as well. I've been able to make the example work by performing the following changes:

1. Configure the following options in the kernel: CONFIG_NFT_FIB, CONFIG_NFT_FIB_INET, CONFIG_NFT_FIB_NETDEV, CONFIG_NFT_FIB_IPV4, CONFIG_NFT_FIB_IPV6, CONFIG_FIB_RULES, CONFIG_NFT_REJECT, CONFIG_NFT_REJECT_NETDEV. If these options are not present, the nft command in line 58 of the example ends with the "Error: Could not process rule: No such file or directory" error message.

2. Run the following commands to initialize the table and chain needed for the rule in line 58:

$ nft add table ip filter # create table

$ nft add chain ip filter output { type filter hook input priority 0 \; } # create chain

$ /etc/init.d/nftables save # to save the above information as default

With the above changes I'm able to connect to the Wireguard endpoint by netifrc and as far as I've tested, network seems to work as expected. It will be great if anyone could also test this approach to ensure it works as expected for everyone.

Dwosky (talk) 11:08, 23 August 2024 (UTC)

Dwosky, I've checked all the CONFIG_* options that you listed in my kernel and they are all already enabled (6.6.47-gentoo). Also, I've tried testing this with the 'ip' table instead of the 'inet' table -- still no dice. One thing I want to add is that the Kernel section should add CONFIG_NF_CONNTRACK_MARK if compiling net-vpn/wireguard-tools with the "wg-quick" USE flag; Portage gave me a warning stating that I needed this CONFIG option. Strangely, Portage doesn't say anything when compiling without this USE flag.

And just to clarify: using WG with "wg-quick" works as expected (WG connects and packets go through the tunnel). Using WG with "netifrc"... WG connects, but no packets are going through the tunnel.

FlyingBullets (talk) 13:15, 23 August 2024 (UTC)

FlyingBullets, is the start command giving you any error? If you get the "Could not process rule: No such file or directory" error message means that you're missing a kernel configuration. ntf usually highlights the part of the rule that's failing. Here's my kernel config if you want to check it out agains yours: https://termbin.com/o4zd --Dwosky (talk) 13:51, 23 August 2024 (UTC)

There is no error; OpenRC goes through the entire startup process via 'rc-service net.wg0 start' without any problems. The nft rule fails because the default nftables rule file is empty, but you can copy-paste a rule set from the Nftables/Examples page and use that. I used the "Typical workstation (combined IPv4 and IPv6)" and changed the nft command to use 'inet' instead of 'ip'.

When you tested it, did you actually have an internet connection? For me, WG found the endpoint and connected to it, but running 'ping gnu.org' failed (wait ~1 minute after WG connects to test for an internet connection). I know for a fact that my kernel and system as a whole is configured properly because everything works when using the wg-quick script.

I don't know what the problem is. I read the wg-quick script (it's literally just a bash script) to see what commands it runs to get it to work. There are only 1-2 commands in the end that are different, that difference however requires deep knowledge of iproute2 and nftables. I compared the routes and tables of both via 'ip route list table all' and 'nft list tables'.

FlyingBullets (talk) 15:00, 23 August 2024 (UTC)

From my side all networking seems to work fine when I enable/start wg0. I can ping/ssh/etc to the IPs in WireGuard's endpoint and I can browse the internet without issues as well. Not sure if it could be something related with the ip routes or rules as you suggest. --Dwosky (talk) 16:17, 23 August 2024 (UTC)

That's because your command,

'nft add chain ip filter output { type filter hook input priority 0 \; }'

has the hook "input"; this is an input chain, not an output chain. The "output" in the command is just the name of the chain, which can be anything. The nft command in postup() will put its rule in a table named "filter" in a chain named "output". nftables will test the rule 'oifname!="wg0" ...' for all incoming packets; this test will fail because it's impossible for an incoming packet to use the output interface of the local machine. This explains why you still have an internet connection because nothing is being rejected.

FlyingBullets (talk) 16:54, 23 August 2024 (UTC)

I've updated the input word for output and it seems to be working the same. One thing I've seen, not sure if its ok or not is that the filter its created with 'policy accept' by default and the priority is 'filter' instead of 0, not sure if that has anything to do:

$ nft list chain ip filter output

table ip filter {

chain output {

type filter hook output priority filter; policy accept;

oifname != "wg0" meta mark != 0x00051a77 fib daddr type != local counter packets 0 bytes 0 reject

--Dwosky (talk) 16:51, 29 August 2024 (UTC)

In the manual page for nftables, man nft:

The policy defines "what happens to packets not explicitly accepted or refused in contained rules. Supported policy values are accept (which is the default) or drop." So, the policy accept; part means to allow packets through the chain by default; this is okay for the output chain because we (the local machine) want to be able to communicate with any other machine.

Again in the manual:

"The priority parameter accepts a signed integer value or a standard priority name which specifies the order in which chains with the same hook value are traversed. The ordering is ascending, i.e. lower priority values have precedence over higher ones." If you take a look at Table 6. Standard priority names, family and hook compatibility matrix, you will see that the value of 0 is the same as the name filter; not to be confused with the chain type filter.

table ip filter {---------> A table NAMED "filter" for the IPv4 address family (this has no effect on the firewall rules).

type filter ...-----------> A chain of TYPE "filter", which is a standard chain type to use in doubt.

... priority filter; ...--> A chain of priority VALUE "filter", which is the value of 0 (raw=-300, mangle=-150, security=50, etc.).

I still believe that packets are not going through your WG interface because the routing commands in /etc/conf.d/net are not working. You might have internet and can ping/ssh/etc. at your WG endpoint, but that doesn't prove that that packets are going through it. Do you have statistics of traffic going through that specific interface at the endpoint? If you watch a 4K video over the internet, do you see the number of sent/received packets on interface wg0 increase?

FlyingBullets (talk) 14:46, 30 August 2024 (UTC)

Update 2:

I managed to walk through the wg-quick script and re-make it without changing the functionality. The following script should work with the following setup:

- WG config file is located in /etc/wireguard/wg0.conf

- Address = and DNS = lines are commented out under [Interface] in the WG config file

- local_ipv4 and local_ipv6 are assigned the values from Address =

FILE simple_wg_quick.bash

#!/bin/bash
nftcmd=''
local_ipv4=''
local_ipv6=''
case"$@"in
up)
iplinkaddwg0typewireguard
wgsetconfwg0/etc/wireguard/wg0.conf
ip-4addressadd"$local_ipv4"devwg0
ip-6addressadd"$local_ipv6"devwg0
iplinksetmtu1420updevwg0
wgsetwg0fwmark51820
ip-4routeadd"0.0.0.0/0"devwg0table51820
ip-4ruleaddnotfwmark51820table51820
ip-4ruleaddtablemainsuppress_prefixlength0
printf-vnftcmd'%sadd table %s %s\n'"$nftcmd""ip""wg0_table"
printf-vnftcmd'%sadd chain %s %s preraw { type filter hook prerouting priority -300; }\n'"$nftcmd""ip""wg0_table"
printf-vnftcmd'%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n'"$nftcmd""ip""wg0_table"
printf-vnftcmd'%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n'"$nftcmd""ip""wg0_table"
printf-vnftcmd'%sadd rule %s %s preraw iifname != "%s" %s daddr %s fib saddr type != local drop\n'"$nftcmd""ip""wg0_table""wg0""ip""$local_ipv4"
printf-vnftcmd'%sadd rule %s %s postmangle meta l4proto udp mark %d ct mark set mark \n'"$nftcmd""ip""wg0_table"51820
printf-vnftcmd'%sadd rule %s %s premangle meta l4proto udp meta mark set ct mark \n'"$nftcmd""ip""wg0_table"
sysctl-qnet.ipv4.conf.all.src_valid_mark=1
ip-6routeadd"::/0"devwg0table51820
ip-6ruleaddnotfwmark51820table51820
ip-6ruleaddtablemainsuppress_prefixlength0
printf-vnftcmd'%sadd table %s %s\n'"$nftcmd""ip6""wg0_table"
printf-vnftcmd'%sadd chain %s %s preraw { type filter hook prerouting priority -300; }\n'"$nftcmd""ip6""wg0_table"
printf-vnftcmd'%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n'"$nftcmd""ip6""wg0_table"
printf-vnftcmd'%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n'"$nftcmd""ip6""wg0_table"
printf-vnftcmd'%sadd rule %s %s preraw iifname != "%s" %s daddr %s fib saddr type != local drop\n'"$nftcmd""ip6""wg0_table""wg0""ip6""$local_ipv6"
printf-vnftcmd'%sadd rule %s %s postmangle meta l4proto udp mark %d ct mark set mark \n'"$nftcmd""ip6""wg0_table"51820
printf-vnftcmd'%sadd rule %s %s premangle meta l4proto udp meta mark set ct mark \n'"$nftcmd""ip6""wg0_table"
nft-f<(echo-n"$nftcmd")
;;
down)
printf-vnftcmd'%sdelete %s\n'"$nftcmd""table ip wg0_table"
printf-vnftcmd'%sdelete %s\n'"$nftcmd""table ip6 wg0_table"
nft-f<(echo-n"$nftcmd")
ip-4ruledeletetable51820
ip-4ruledeletetablemainsuppress_prefixlength0
ip-6ruledeletetable51820
ip-6ruledeletetablemainsuppress_prefixlength0
iplinkdeletedevwg0
;;
esac

I will be working on a version that combines the ip and ip6 tables into a single inet table. If anyone has problems with this script, please let me know; this script should work regardless of your nftable configuration because it creates a new, independent table.

FlyingBullets (talk) 22:06, 5 September 2024 (UTC)

Update 3:

Success! Here is the inet version (same setup required for original):

FILE simple_wg_quick_v2.bash

#!/bin/bash
nftcmd=''
local_ipv4=''
local_ipv6=''
wg_iface='wg0'
wg_fwmark='51820'
wg_routing_table='51820'
case"$@"in
up)
iplinkadd"$wg_iface"typewireguard
wgsetconf"$wg_iface"/etc/wireguard/"$wg_iface".conf
ip-4addressadd"$local_ipv4"dev"$wg_iface"
ip-6addressadd"$local_ipv6"dev"$wg_iface"
iplinksetmtu1420updev"$wg_iface"
wgset"$wg_iface"fwmark"$wg_fwmark"
sysctl-qnet.ipv4.conf.all.src_valid_mark=1
# Allowed-IPs.
ip-4routeadd"0.0.0.0/0"dev"$wg_iface"table"$wg_routing_table"
ip-6routeadd"::/0"dev"$wg_iface"table"$wg_routing_table"
ip-4ruleaddnotfwmark"$wg_fwmark"table"$wg_routing_table"
ip-6ruleaddnotfwmark"$wg_fwmark"table"$wg_routing_table"
ip-4ruleaddtablemainsuppress_prefixlength0
ip-6ruleaddtablemainsuppress_prefixlength0
# Keep nftables atomic.
printf-vnftcmd'%sadd table %s %s\n'"$nftcmd"inet"${wg_iface}_nftable"
printf-vnftcmd'%sadd chain %s %s preraw { type filter hook prerouting priority -300; }\n'"$nftcmd"inet"${wg_iface}_nftable"
printf-vnftcmd'%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n'"$nftcmd"inet"${wg_iface}_nftable"
printf-vnftcmd'%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n'"$nftcmd"inet"${wg_iface}_nftable"
printf-vnftcmd'%sadd rule %s %s preraw iifname != "%s" %s daddr %s fib saddr type != local drop\n'"$nftcmd"inet"${wg_iface}_nftable""$wg_iface"ip"$local_ipv4"
printf-vnftcmd'%sadd rule %s %s preraw iifname != "%s" %s daddr %s fib saddr type != local drop\n'"$nftcmd"inet"${wg_iface}_nftable""$wg_iface"ip6"$local_ipv6"
printf-vnftcmd'%sadd rule %s %s postmangle meta l4proto udp mark %d ct mark set mark \n'"$nftcmd"inet"${wg_iface}_nftable""$wg_fwmark"
printf-vnftcmd'%sadd rule %s %s premangle meta l4proto udp meta mark set ct mark \n'"$nftcmd"inet"${wg_iface}_nftable"
nft-f<(echo-n"$nftcmd")
;;
down)
nftdeletetableinet"${wg_iface}_nftable"
ip-4ruledeletetable"$wg_routing_table"
ip-6ruledeletetable"$wg_routing_table"
ip-4ruledeletetablemainsuppress_prefixlength0
ip-6ruledeletetablemainsuppress_prefixlength0
iplinkdeletedev"$wg_iface"
;;
esac

My next goals were:

- find out what parts I do and don't need

- find out how to merge this script with /etc/conf.d/net

- who knows from there...

But, while reading the official WG documentation, I found that this is a "Classic Solution" and that there is a "New Namespace Solution" that has some benifits such as being able to selectively route commands outside the WG tunnel without having to shut down the tunnel; I will be working on a script that implements this namespace solution.

For now, this inet implimentation of the wg-quick script should work.

FlyingBullets (talk) 22:22, 5 September 2024 (UTC)

Update 4:

I have completed the "New Namespace Solution" and am currently working on the wiki changes. :3

FlyingBullets (talk) 14:17, 2 October 2024 (UTC)

Update 5:

I have completed the changes to the Wiki. If anyone has any questions, comments, or concerns about the new "Network Namespaces" section, let me know.

FlyingBullets (talk) 00:07, 3 October 2024 (UTC)

Rewite

I intend to rewrite this page. The rewrite is nearly done. It doesn't use the mark-and-mangle method but instead uses routes and metrics. I've also put instructions for the 5 major Gentoo clients: the manual way, wg-quick, netifrc, NetworkManager, and systemd-networkd, both a split tunnel and full tunnel version. In structions for servers for manual, wg-quick, netifrc, and systemd-netowrkd are there as well. I'm pretty confident of my split tunnel and I've tested them in my homelab, but full tunnels are less tested. I also moved FlyingBullets scripts into a subpoage and linked it from the main page. Comments and testing appreciated! 00:04, 1 February 2026 (UTC)

I agree that the WireGuard article is a mess and it should be redone. I took a quick peek at your rewrite and think it can be better formatted. Your rewrite seems to be longer than the current one and has more sections, for something like WireGuard--which should be simple to set up--this is too daunting for newcomers; when I first came to this article, it was already a lot to take in.

That being said, here's my two cents: the main WireGuard article should be small and point to sub-articles of different implementations (manual, wg-quick, netifrc, etc.). I don't like the split between "Clients" and "Server" sections; they should be together under a specific implementation. See Power management to understand what I mean: a simple main article and simple sub-articles. "Manual", "wg-quick", etc. should have their own sub-articles with the instructions on how to set them up.

The main article should contain generic information that can apply to all implementations.

I'm not an expert on WireGuard, nftables, nor iproute2; so, I have to ask: what is the benefit to using routes and metrics instead of mark-and-mangle? Also, what's the difference between split and full tunnel?

FlyingBullets (talk) 02:56, 1 February 2026 (UTC)

I can split it up, although I'll have to think on what lines to split it under. Maybe create a subpage for each implementation? Perhaps split out the server side into a separate article? Maybe both? Although WireGuard is a far simpler VPN than ipsec, it turns out, network-wise, VPNs are complicated. Many VPN providers provide their own GUI (which are generally wrappers around wg-quick and work poorly with netifrc/NwtworkManager/systemd-networkd) for this reason.

The difference between split-tunnel and full-tunnel is important.

Split-tunnel routes SELECTED traffic over the tunnel. For split-tunnel the only configuration that needs to be done is to set the WireGuard AllowedIPs to the network(s) to access. For example, take the case of someone wanting to access their home network. A split tunnel would be appropriate. The AllowedIPs on the client would be set to the tunnel IP range (like 172.24.137.0/24) and the LAN IP range (like 192.168.50.0/24); network access outside this (like the Internet) do not go through the tunnel. If there are resource behind the tunnel, configuring WireGuard is easy, but configuring IP settings, such as forwarding and (if the WireGuard server isn't the default gateway) NAT is considerably harder.

Full-tunnel routes ALL traffic over the tunnel. Full-tunnel configuration requires additional routing rules on the client. The main part is the default gateway on the client needs to be set to point to the tunneled IP of VPN server. By making the metric lower than the other routes, directly connected networks (like a LAN) are still accessible in full-tunnel mode. For example, take the case of someone wanting to make them appear in a different part of the world than they really are. A full tunnel would be required for that to work. The AllowedIPs is set to 0.0.0.0/0, the client sets the default gateway correctly, and all non-directly connected traffic. like Internet traffic, goes through the tunnel. The "defensive routes" are just there to stop routing loops, but I don't think they are actually required.

The advantage to using routes and metric over mark-and-mangle is that for some setups is considerably more difficult (and maybe impossible) to set up policy routes for. Understand simple routing is hard enough, policy routing compounds that. Both wg-quick and NetworkManager use the mark-and-mangle with policy routing be default for a full-tunnel configuration (even if a fwmark isn't specified), and it has an advantage: You don't need to know the default gateway on the server, and there's no need for defensive routes. The disadvantage is that its ugly, and although a valid method, seems like the "wrong" way to handle this. If I do split the the configurations in subpages, I can provide both methods for the manual, openrc, and systemd-networkd methods.

Salahx (talk) 05:06, 1 February 2026 (UTC)

I agree with Salahx proposition to use IP routing examples over some firewall setup example. The terms full-tunnel and split-tunnel are the 2 basic setup procedures. IP routing plus wireguard and are more easy to setup and to explain with linux IP routing and wg only, instead of using some firewall for that use-case. One can always add nft or iptables over it to this article, yes. However if a) linux IP routing and 2) wg setup are not properly setup, troubleshooting the firewall settings will not help the reader, it only adds another level of complexity to take care of. This way the reader has only 2 pieces of software to troubleshoot iproute2 and wg. With firewall you have 3 pieces of software to troubleshoot, iproute2, wg and nft or iptables. A packetfilter (iptables or nft) is not necessarily needed to setup both examples. Firewall is only (nice to have) from the technical point and from the setup point of view. Needle (talk) 10:51, 1 February 2026 (UTC)

Interestingly, both wg-quick and NetworkMananger' use the "routes and metric" approach of "mark-and-mangle" pproach for split tunnels (If there are resources bind the tunnel - that is, additional AllowedIPs - the client needs one extra route per netowrk. This is something I forgot). Salahx (talk) 16:02, 1 February 2026 (UTC)

My concern is only using metrics and routing. Sure, setting the default route to the tunnel as the highest priority sends packets through the tunnel, but without "fwmark"s, packets can leak.

FlyingBullets (talk) 21:42, 2 February 2026 (UTC)

In the split-tunnel case it doesn't matter: The other networks will be inaccessible out the tunnel. For the full-tunnel case I'm not seeing how it could leak with my suggested configuration (except intentionally leaking the endpoint itself to avoid routing loops). Note that only the manual and systemd-networkd method could use fwmark/policy routing, netifrc has no support for this (well, it can be done but its really ugly).Under what circumstance could it leak in a full tunnel? Salahx (talk) 22:38, 2 February 2026 (UTC)

I think it may be cleaner to have the type of tunnel with subsections for each type of network manager Zen desu (talk) 23:57, 2 February 2026 (UTC)

That was something I considered, the problem is each type of network manager needs its own introduction, in particular systemd-networkd with the use of credentials; and to wg-quick to point out it's better not to use it, so that it can properly managed. I'm trying to have the reading jump back and forth between sections to get what they need: They read the introduction. pick their scenario, and plug in the correct values. Salahx (talk) 00:27, 3 February 2026 (UTC)

I think having the reader jump back and forth between sections is a horrible idea because you have to assume the reader doesn't know what they need. An article should instruct the reader on what they need to do going down the page. If the article is telling the reader to scroll back up, that's the articles' fault; it's okay to skip sections, but following sections #1, #3, #2 is not intuitive. If each type of network manager *needs* its own introduction, then just put the introduction in its own sub-article and/or put a brief description in the main article.

FlyingBullets (talk) 00:18, 4 February 2026 (UTC)

I made a mistake in my above statemeent: I mean I'm trying NOT to have the reader jump back and forth between sections to get what they need, but I forgot the "not". Right now the way I have I now, readers pick the which supervisor they have, and then choose their scenario. Really, only two of the of the client need special introductions: wg-quick and systemd-networkd. I assume most VPN providers prefer wg-quick (or their own GUI app which is a wrapper around it), which is something undesirable when there's a network supervisor. systemd-networkd wants credentials, and systemd-creds(1) and most of the rest systemd documentation offers no clue as to where to place those credentials. Salahx (talk) 23:29, 5 February 2026 (UTC)

I've had packets leak in a full tunnel when the WireGuard tunnel disconnects. This is explained in the official documentation: https://www.wireguard.com/netns/ under the section "Overriding The Default Route"; this is the reason why I made custom scripts and a section explaining how to implement the namespace solution using the official documentation section "The New Namespace Solution".

FlyingBullets (talk) 00:18, 4 February 2026 (UTC)

I hadn't thought about someone restarting the main interface or a dhcp client refresh clobbering the route. That could cause problems on a full tunnel. For manual we don't care anyway; wg-quick and NetworkManager use marking and policy routing. That just leaves netifrc and systemd-networkd. I see they've thought this through; I'm going to need to re-evalute and experiment some more. Salahx (talk) 19:04, 4 February 2026 (UTC)

Ok, the WireGuard developers have made a pretty good case for fmark+policy routing. It turns out netifrc does support policy routing, so I changed all the examples to use that, as well as added a footnote for the "why". Salahx (talk) 19:04, 4 February 2026 (UTC)

I refactored the rewrite by scenario, then client instead of by client, then scenario per the suggestion above. The sections are shorter now but the now there's more of them Salahx (talk) 21:30, 6 February 2026 (UTC)

I'm busy at the moment, but I'll read your rewrite soon.

FlyingBullets (talk) 18:39, 8 February 2026 (UTC)

Okay, so I've been reading the WireGuard rewrite and here are my thoughts:

* Things aren't explained enough; I read what "full tunnel", "split tunnel - tunnel-only", and "split-tunnel - access behind tunnel" are in the TIP and NOTE boxes at the top, but the wording just sounds like, "you can tell this is a tree because of the way it is". It doesn't go into detail on the "why" and "how"; there are also no examples. To understand what I mean, read the introduction to the "Network Namespaces" section in the current WireGuard article.

* You need to remove the "jumping around" thing. I see what you're trying to do, but this is not the way to do it. I don't know of any other Gentoo wiki article that does this... it doesn't feel intuitive. The reader should progress through the article going down.

* I'm going to appear bias on this one because I'm the one that made it, but no one is going to read the network namespaces solution if it's at the bottom in a "See also".

FlyingBullets (talk) 20:51, 25 February 2026 (UTC)

Network Namespaces

I think this is awesome documentation to have, but the supplied script is massive, and the configuration is quite extensive. I think this wiki might not be the best place for it, and it should instead be a separate project or a package. I found at least two projects that do a similar job[1] [2] [3], and a tutorial on how to use one solution[4]. Mid-kid (talk) 00:21, 22 February 2026 (UTC)

In by rewrite (by solution vs by supervisor), i separate it into its own page. (I personally prefer "by supervisor" rather than "by solution" but other seem to prefer it that way) Salahx (talk) 00:35, 22 February 2026 (UTC)

Yeah, I know it's massive, the WikiMedia format doesn't have support for a "Drop-down FileBox". Most of its size comes from features that wg-quick has, plus the ability automatically tell which services to use the tunnel and not. The biggest problem is that OpenRC's current implementation of network namespaces doesn't support moving interfaces across namespaces (it only supports making them), which is a required step when setting up the namespace solution. If OpenRC fully supported network namespaces, the script isn't needed and the logic can simply be in /etc/conf.d/net with fewer lines of code.

FlyingBullets (talk) 21:05, 25 February 2026 (UTC)

• Closed discussions
• Solved discussions
• Open discussions