Add wg-quick deep dive postHEADmaster

1 files changed, 511 insertions, 0 deletions

diff --git a/posts/wg-quick-deep-dive/main.md b/posts/wg-quick-deep-dive/main.md
new file mode 100644
index 0000000..5f671fe
--- /dev/null
+++ b/posts/wg-quick-deep-dive/main.md
@@ -0,0 +1,511 @@
+`wg-quick(8)` on Linux - a deep dive
+====================================
+
+Perhaps you have decided to secure your company's internal database or tunnel all your traffic through a VPN.
+You enter the command wg-quick up wg0, watch as commands scroll past your screen, and suddenly realize you
+can't access the network.
+
+If this situation sounds familiar, you're not alone. WireGuard is a Layer 3 VPN that has become the de-facto
+standard for good reasons — it's fast, simple, and secure. Anecdotally, it's known to be easier to configure
+than its bulkier and more convoluted predecessor, OpenVPN. However, configuring or debugging WireGuard networks
+requires a robust understanding of networking, something the thorough WireGuard
+[documentation](https://www.wireguard.com/#conceptual-overview) can help most users with.
+
+I recently reviewed the source for `wg-quick(8)` and discovered that it was not entirely documented. Some of the documented
+parts assumed an in-depth understanding of networking. This research turned out to be a surprisingly
+instructive exercise in Linux networking, and I'm sharing my results here. Hopefully, it can fill in some gaps in the
+existing documentation.
+
+In particular, this guide:
+
+1. Provides additional exposition on Linux networking
+2. Details default-route handling
+3. Explains the default firewall configuration
+4. Describes the multicast limitations of WireGuard tunnels
+
+The Basics
+----------
+
+WireGuard adheres to the Unix philosophy of "doing one thing well," fostering a design of modular systems.
+Accordingly, it integrates into the Linux networking stack as a network interface, configured
+through the user space tool `wg(8)`. However, to enable traffic flow, IP addresses must be assigned, and
+routes need to be configured. While this is a relatively simple procedure, it can become tedious and requires
+automation to ensure reliability. This is where `wg-quick(8)` steps in.
+
+> This is an extremely simple script for easily bringing up a WireGuard interface, suitable for a few
+common use cases. ... Generally speaking, this utility is just a simple script that wraps invocations
+to `wg(8)` and `ip(8)` in order to set up a WireGuard interface. It is designed for users with simple
+needs, and users with more advanced needs are highly encouraged to use a more specific tool, a more
+complete network manager, or otherwise just use `wg(8)` and `ip(8)`, as usual.
+>
+> \- `wg-quick(8)`
+
+`wg-quick` serves as a straightforward orchestration tool for creating and removing WireGuard tunnels.
+It is the de-facto standard for configuring tunnels since it is cross-platform, supported by all official
+clients. Its strength lies in the fact that the configuration provides a complete description of the tunnel,
+allowing tunnels to be brought up or down with a single command. Additionally, the interface can be initiated
+at boot through systemd, although - oddly - this feature remains undocumented. Without additional tooling, `wg-quick`
+can configure either a static server endpoint or a roaming peer.
+
+A "static server endpoint" refers to a computer with a static IP, typically provided by cloud computing vendors,
+which functions as a node connecting peers. Often, it may facilitate access to protected resources, like a database.
+A roaming peer, on the other hand, is a machine that connects using the static IP of the server and can access the
+server or other peers. Peers typically lack a fixed endpoint and "roam" from one IP to another.
+
+There's also a special provision for cases where a peer routes all their internet traffic through the tunnel, aligning
+with how most consumers conceive of a VPN. However, VPNs can also selectively transmit traffic bound for specific
+computers. Unfortunately, the server configuration for this setup cannot be handled with wg-quick alone since it
+necessitates Network Address Translation (NAT). This limitation likely stands as an exception, enabling VPN providers
+to distribute `wg-quick` configurations instead of writing their own tools to route traffic.
+
+wg-quick is by no means the sole configuration tool for WireGuard. It's supported alongside other network management
+systems such as networkd and NetworkManager. Specifically, NetworkManager is a prevalent tool for managing WiFi networks
+on desktop environments, and it has the capability to import WireGuard tunnels using the .conf format, just like wg-quick.
+(The extent of feature compatibility between them, however, is something I'm not fully aware of at the moment.) On the
+other hand, networkd is more commonly leveraged for network management on servers. In the near future, I'll be releasing a
+tool that can "import" (or more accurately, transpile) wg-quick files into networkd configurations. When choosing between
+these options, it would be wise to defer to your system's network manager. Most users configure WireGuard tunnels within
+the initial network namespace. Multiple tools can end up tripping over one another while
+managing the same network resources.
+
+It is also worth stating that `wg-quick` is not the only configuration tool. WireGuard is supported both by
+`networkd` and `NetworkManager`. `NetworkManager` is commonly used to manage WiFi networks on the desktop
+and can import WireGuard tunnels using the `.conf` format shared with `wg-quick`. (Although I am unaware of
+the feature compatibility.) `networkd` is commonly used to manage networks on the server. Soon, I will be
+releasing a tool I wrote which allows `wg-quick` files to be "imported" (or more accurately transpiled) to
+`networkd`. When considering which option to use, I would default to your system's network manager. WireGuard
+tunnels affect resources in the global network namespace, so it makes sense for them to be managed by an entity
+responsible for managing network resources globally.
+
+The process of manually configuring a WireGuard tunnel is thoroughly outlined on the [quickstart page](https://www.wireguard.com/quickstart/).
+If you've set up a network with static IP addresses, you might already be acquainted with this process. However, many
+enthusiasts and developers may have avoided this route, since the aptly named Dynamic Host Configuration Protocol (DHCP)
+takes care of automating IP management.  In the following section, I'll delve into configuring network interfaces on Linux,
+assuming that you possess a fundamental understanding of networking concepts. Should you be new to setting up a static network,
+or if you find yourself unfamiliar with terms like private IP address space, subnets, public IPs, routers, subnet masks, and
+interfaces, I strongly recommend taking the time to acquaint yourself with these concepts before proceeding.
+
+### Revisiting a Simple Network
+
+WireGuard seamlessly integrates with the Linux networking stack, functioning as a networking interface. The Linux networking
+system is indeed robust, supporting a wide array of features. However newcomers should be warned, the documentation often appears
+to lag behind the pace of feature development. In this article, we'll explore the fundamentals of a simple Local Area Network (LAN)
+and shed light on how packets are routed on contemporary Linux systems. This foundational knowledge is essential for understanding
+how `wg-quick` interfaces with these routing constructs.
+
+Assigning a static IP address to a networking interface can be accomplished using the following command. This sets up a LAN with the
+subnet `192.168.0.0-127` and assigns the networking interface the IP address `192.168.0.22`:
+
+```
+[#] ip -4 addr add 192.168.0.22/25 dev eth0
+```
+
+Should you attempt to transmit data to a peer at `192.168.0.11` (e.g., using a UDP socket), how does the kernel determine where to
+route these packets? Upon executing the command above, the kernel modifies a structure known as the routing table. Routing tables
+function as a database, directing traffic to a specific interface by matching the destination IP address. Most routes are automatically
+appended to the `main` routing table, which can be viewed with the command `ip route show`:
+
+```
+[#] ip -4 route show table main
+
+192.168.0.0/25 dev eth0 proto kernel scope link src 192.168.0.22
+```
+
+In essence, packets destined for our subnet will be sent using eth0 with the source IP address `192.168.0.22`. The kernel
+automatically adds this route for a subnet assigned to a link, known as a prefix route. If multiple competing routes
+exist in a routing table, the route is selected using the longest prefix match algorithm. Essentially, the most specific
+route, characterized by the longest subnet mask, is chosen. If you add a custom route specifying that `192.168.0.11/32`
+should be sent using eth1, traffic will flow through this interface instead, since the 32-bit subnet mask is longer than
+the 25-bit subnet mask:
+
+```
+[#] ip -4 route add 192.168.0.11/32 dev eth1
+[#] ip -4 route get 192.168.0.11
+192.168.0.11 dev eth1 src 192.168.0.12 uid 0
+    cache
+```
+
+This brings up an intriguing question: If we send traffic to the current host at `192.168.0.22`, how does the routing
+algorithm determine that the packets shouldn't leave the computer but instead be handled by local programs? The answer
+lies in another table that precedes the `main` table, known as the `local` table. The `local` table is consulted before
+the `main` table, and if a match is found, the packet is routed accordingly. The kernel also manipulated this table in
+response to our earlier `ip addr add` command.
+
+```
+[#] ip -4 route show table local
+
+local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
+local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
+broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
+local 192.168.0.22 dev eth0 proto kernel scope host src 192.168.0.22
+broadcast 192.168.0.127 dev eth0 proto kernel scope link src 192.168.0.22
+```
+
+The original ip addr add command added both a local route and a broadcast route. Specifically, the entry `local 192.168.0.22 dev eth0`
+stipulates that packets addressed to `192.168.0.22` should be "looped back" and delivered to sockets listening locally on `eth0`, or
+bound to the address `192.168.0.22`. Typically, IP traffic is unicast, meaning it originates with one host and is directed at another.
+The `broadcast` rule informs the kernel that `192.168.0.127` is a broadcast address. By default, the kernel utilizes the highest IP
+address in the subnet as the broadcast address.
+
+The above overview offers almost a complete picture, but there's another crucial layer of indirection in play: the Routing Policy Database
+(RPDB). The RPDB acts as a guide, specifying how routing tables are selected and ordered. This can be queried with the ip rule command, and
+the initial state of the RPDB might look something like this:
+
+```
+[#] ip rule
+
+0:	from all lookup local
+32766:	from all lookup main
+32767:	from all lookup default
+```
+
+
+Quoting directly from the manual provides a comprehensive explanation:
+
+> Each policy routing rule consists of a selector and an action predicate.  The RPDB is scanned in order of decreasing priority (note that a lower number means
+higher priority, see the description of PREFERENCE below). The selector of each rule is applied to {source address, destination address, incoming interface,
+tos, fwmark} and, if the selector matches the packet, the action is performed. The action predicate may return with success.  In this case, it will either give
+a route or failure indication and the RPDB lookup is terminated. Otherwise, the RPDB program continues with the next rule.
+>
+> Semantically, the natural action is to select the nexthop and the output device.
+>
+> At startup time the kernel configures the default RPDB consisting of three rules:
+>
+> 1. Priority: 0, Selector: match anything, Action: lookup routing table local (ID 255).  The local table is a special routing table containing high priority
+> control routes for local and broadcast addresses.
+> 2. Priority:  32766,  Selector: match anything, Action: lookup routing table main (ID 254).  The main table is the normal routing table containing all non-
+>  policy routes. This rule may be deleted and/or overridden with other ones by the administrator.
+> 3. Priority: 32767, Selector: match anything, Action: lookup routing table default (ID 253).  The default table is empty. It is reserved for some post-pro‐
+ cessing if no previous default rules selected the packet.  This rule may also be deleted.
+>
+> \- ip-rule(8)
+
+If you've been following along, you now understand that when a socket binds or connects to an address, the kernel
+selects an appropriate route by querying the routing tables. This query is guided by the rules specified in the
+routing policy database (RPDB). When a table contains multiple routes, the longest prefix match algorithm is used
+to determine the most specific route, and that is the one selected.
+
+_Note:_ Policy routing can be bypassed using the `SO_BINDTODEVICE` option. This allows you to bind a socket directly
+to a specific device, effectively sidestepping the standard routing process.
+
+### Bringing Up a Site-to-Site-Style Tunnel with `wg-quick(8)`
+
+> Use up to add and set up an interface, and use down to tear down and remove an interface. Running up
+adds a WireGuard interface, brings up the interface with the supplied IP addresses, sets up mtu and
+routes, and optionally runs pre/post up scripts.
+>
+> \- wg-quick(8)
+
+The command `wg-quick` first searches for a configuration file. If the first argument to `wg-quick up` matches
+the pattern `[a-zA-Z0-9_=+.-]{1,15}`, which represents a valid interface name on Linux, the file is assumed
+to exist in `/etc/wireguard` with the provided name and a `.conf` extension. Once a suitable file is found,
+its contents are read. For example, it might read the following file, `wg0.conf`:
+
+```
+[Interface]
+PrivateKey = yDdqzxdE66e64xy5Qu1PshT0ybQJLHbU9N+91PS1Dng=
+Address = 192.168.42.1/24
+
+[Peer]
+PublicKey = o837llPmQ4t9cN0rmiLasp6SF54dAzS0Ea1p71c1jFA=
+AllowedIPs = 192.168.42.0/32
+Endpoint = 19.216.242.139:16262
+
+[Peer]
+PublicKey = YIUKiCiw9+6an3HnDn7t3CwlF30ERQkhEQ6f3jRBUnk=
+AllowedIPs = 10.1.0.0/16
+Endpoint = 19.216.242.138:16263
+```
+
+The process begins identically to the steps taken in the quick start documentation. A WireGuard interface is
+added to the system with the interface name from the corresponding file:
+
+```
+ip link add dev wg0 type wireguard
+```
+
+Then, the WireGuard configuration is obtained by stripping out the `wg-quick`-specific sections, passing the
+rest to the `wg` command. This configuration can be produced using the `wg-quick strip` command. Running
+`wg-quick strip` on the above example removes the Address section, and wg parses the configuration to pass it
+on to the kernelspace driver [1].
+
+[1] It can also communicate this information to the userspace implementation, if available.
+
+```
+[#] wg-quick strip wg0.conf
+[Interface]
+PrivateKey = yDdqzxdE66e64xy5Qu1PshT0ybQJLHbU9N+91PS1Dng=
+
+[Peer]
+PublicKey = o837llPmQ4t9cN0rmiLasp6SF54dAzS0Ea1p71c1jFA=
+AllowedIPs = 192.168.42.0/32
+Endpoint = 19.216.242.139:16262
+
+[Peer]
+PublicKey = YIUKiCiw9+6an3HnDn7t3CwlF30ERQkhEQ6f3jRBUnk=
+AllowedIPs = 10.1.0.0/16
+Endpoint = 19.216.242.138:16263
+```
+
+As the official documentation states:
+
+> The configuration file adds a few extra configuration values to the format understood by wg(8) in order
+to configure additional attributes of an interface. It handles the values that it understands, and then
+it passes the remaining ones directly to wg(8) for further processing.
+>
+> \- wg-quick(8)
+
+The way the interface configuration affects packet routing is well-covered by the
+[original documentation](https://www.wireguard.com/#simple-network-interface). If you haven't read it, you
+should explore the "Simple Network Interface" and "Cryptokey Routing" sections before continuing.
+
+```
+[#] wg-quick strip wg0.conf > wg0-stripped.conf
+[#] ip setconf wg0 wg0-stripped.conf
+```
+
+Next, the IP addresses specified in Addresses are added to the interface. For the above configuration,
+it assigns the IP address `192.168.42.1` to the WireGuard interface. This becomes the source IP address
+for packets traveling to the peer VPN endpoint [3]. The system also automatically creates a prefix route
+directing traffic from any IP address matching `192.168.42.0/24` to the interface `wg0`, and a local route
+for `192.168.42.1`.
+
+[3] The source IP address, as defined in the Addresses section of the configuration, serves as the originating
+address for packets sent to the peer VPN endpoint. However, this can be overridden using a "raw socket," in which
+an application has the ability to define all fields of a packet, including the source IP. While this introduces
+significant security considerations, WireGuard's Cryptorouting scheme substantially mitigates the risks. Malicious
+peers are restricted to spoofing only those addresses listed in the `AllowedIPs` section of the `[Peer]` configuration,
+and all unauthorized packets are promptly dropped. This built-in mechanism aids in containing potential threats.
+
+```
+[#] ip -4 addr add 192.168.42.1/24 dev wg0
+```
+
+Afterward, the link is brought up, and the MTU (Maximum Transmission Unit) is set. The MTU represents the maximum size
+of a packet that can be communicated on a link. If unspecified, the MTU of the underlying link is obtained, and the MTU
+of the WireGuard tunnel is reduced by 80 bytes to exclude the overhead of the WireGuard encapsulation packets. I looked
+into this and am still unsure as to why an 80 byte MTU reduction was chosen. My working theory is that this value was
+chosen to cover both IPv4 and IPv6 with a factor of safety [4].
+
+[4] The encapsulation method depends on whether the tunnel endpoint is an IPv4 address or an IPv6 address. The maximum
+size of an IPv4 packet is 60 bytes. IPv6 packets are more challenging to quantify since they can have any number of
+arbitrary header extensions. The base IPv6 header is only 40 bytes but additional headers can add up. Accordingly, 80
+bytes would cover an IPv6 header with a few extensions.
+
+
+```
+[#] ip link set mtu up 1420 dev wg0
+```
+
+Finally, routes are added for all the entries of `AllowedIPs` to the `main` routing table:
+
+```
+[#] ip -4 route add 192.168.42.0/32 dev wg0
+[#] ip -4 route add 10.1.0.0/16 dev wg0
+```
+
+### Default-Route Handling
+
+The above example illustrates how WireGuard establishes static routes for specific segments of the IP space, which we
+specified in `AllowedIPs`. However, these previous examples assumed that the peer endpoint falls outside any of the
+`AllowedIP` ranges. If this were not true, the routes would create a routing loop, with packets exiting the WireGuard
+interface being routed back into it.
+
+One common use case for a VPN is to route all traffic to an endpoint which functions as a NAT router. (If you are unfamiliar
+with NAT, picture your home router home router.) This can enhance privacy, reduce the specificity of a user's public IP address
+in fingerprinting systems, prevent ISPs from selling data to advertisers, or obscure the regional ISP an individual is using.
+To route all traffic, we need a default route `0.0.0.0/0` and `::0/0` which match all destination IPs. This creates an issue
+since our endpoint's IP will fall into this range. Fortunately, there are methods to make default routes work as intended.
+
+Linux policy routing can be used in various ways to solve this problem, and the
+[Wireguard Routing and Namespace Documentation](https://www.wireguard.com/netns/#routing-all-your-traffic) outlines a few potential
+solutions. `wg-quick` elegantly accomplishes this with the following rules, which require some explanation:
+
+
+```
+[#] wg set wg0 fwmark 51820
+[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
+[#] ip -4 rule add not fwmark 51820 table 51820
+[#] ip -4 rule add table main suppress_prefixlength 0
+```
+
+The Linux kernel routing system features `fwmark`, an integer marker ranging from `0` to `2^32 - 1` which can be attached to a packet.
+It designates that the packet should be routed or filtered according to special rules. Packets with this mark can either be routed to
+a specific table using policy routing (`ip-rule`) or filtered with the `nftables` framework. The `fwmark` can be set either within the
+`netfilter` subsystem or by a program when making a network connection [4].
+
+[4] `setsockopt` can be used with `SO_MARK` to set the outgoing mark as so long as the process has the `CAP_NET_ADMIN` capability.
+
+In this instance, wg-quick marks all packets leaving the tunnel with the `fwmark` 51820:
+
+```
+[#] wg set wg0 fwmark 51820
+```
+
+Recall our previous discussion of routing tables. `wg-quick` creates a new routing table within which the default route directs all
+traffic to the `wg0` interface, effectively serving as a "default gateway." With none of the mask bits set, all traffic is routed to `wg0`:
+
+```
+[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
+```
+
+Traffic must then be directed to this routing table. Here, all traffic that has not exited the VPN interface (and thus does not have
+this fwmark) is sent to the table with the default route:
+
+```
+[#] ip -4 rule add not fwmark 51820 table 51820
+```
+
+By default, the IP command assigns this rule a higher priority than the rule querying the main table.
+
+```
+[#] ip rule
+0:	from all lookup local
+32765:	not from all fwmark 0xca6c lookup 51820
+32766:	from all lookup main
+32767:	from all lookup default
+```
+
+We have established that traffic will be directed through the Wireguard interface if it does not match any local IP ranges. It will
+then be sent through `wg0` before being routed according to the `main` table (and likely exit through a default gateway.)
+
+The `ip rule` command prints the mark in hex as `0xca6c`.
+
+#### Handling Local Network Traffic
+
+While VPN traffic will flow as expected, this configuration may have unintended consequences. All local LAN traffic will be directed
+to the tunnel, preventing access to the local network (except for encrypted Wireguard packets directed to the default gateway).
+Policy routing has one more trick:
+
+```
+[#] ip -4 rule add table main suppress_prefixlength 0
+```
+
+The command `suppress_prefixlength` rejects all routes with prefixes equal to or less than the specified length. So, `suppress_prefixlength 0`
+rejects all default gateways, causing the routing algorithm to query the main table first, which typically contains LAN routes but can also
+contain routes setup by virtualisation software.
+
+These rules are set whenever the default IPv4 `0.0.0.0/0` or `IPv6 ::/0` routes appear in the `AllowedIPs`. In the case of IPv6, `ip -6` rules
+are added as well. Finally, if `FwMark` is not specified, `wg-quick` searches for the next available mark, stopping when an empty routing table
+is found. Finally, the `FwMark` is set to the routing table number.
+
+### The Default Firewall
+
+wg-quick configures a firewall if nftables is installed and a default route is specified. The following firewall rules are
+setup when an IPv4 endpoint is specified:
+
+```
+table ip wg-quick-wg0 {
+	chain preraw {
+		type filter hook prerouting priority raw; policy accept;
+		iifname != "wg0" ip daddr 192.168.42.1 fib saddr type != local drop
+	}
+
+	chain premangle {
+		type filter hook prerouting priority mangle; policy accept;
+		meta l4proto udp meta mark set ct mark
+	}
+
+	chain postmangle {
+		type filter hook postrouting priority mangle; policy accept;
+		meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark
+	}
+}
+```
+
+The first rule in the preraw chain mitigates a potential vulnerability that could allow a network attacker to access servers
+listening on `wg0`. It's easy to assume that local services listening on the WireGuard IP address are safe since they're only
+accessible to those connected to the tunnel. However, this is not the case.
+
+Imagine an attacker connected on `eth0`, an adjacent ethernet interface, attempting to access the address assigned to our WireGuard
+interface, `192.168.42.1`. Since a route for this address is in the `local` table, the attacker can send packets to `192.168.42.1`
+and receive responses, even if the requests originate from another subnet. This could enable the attacker to exfiltrate sensitive
+data or inject malicious packets. Therefore, the first rule enforces that services on `wg0` can only be accessed through addresses on
+the same interface.
+
+#### Reverse Path Forwarding
+
+The last two rules in the code snippet above pertain to reverse path forwarding, a technique used to prevent spoofed packets from entering
+a network. Consider a router with forwarding enabled and two links:
+
+```
+172.30.1.0/31 dev eth-01 proto kernel scope link src 172.30.1.0
+172.30.2.0/31 dev eth-02 proto kernel scope link src 172.30.2.0
+```
+
+Now, think about a scenario where a router connected to `eth-02` with IP `172.30.2.1` and an attacker connected to this router attempt to perform
+a denial-of-service attack against `1.1.1.1` by spoofing network ICMP packets with random destination IPs and the source address of their victim.
+Classically, if one of these spoofed packets "from" `1.1.1.1` destined for `172.30.2.1` arrives on `eth-01`, it would be forwarded. However, this
+would be suspicious since a packet from `172.30.2.1` destined for `1.1.1.1` would be dropped, not forwarded through `eth-02`. By considering if a
+routable path exists in the reverse direction, a router can automatically drop spoofed packets. This concept is known as reverse path forwarding,
+as defined by RFC 3704, known as "strict reverse path forwarding."
+
+To enable strict reverse path filtering in the Linux kernel, you can use the following sysctl switch:
+
+```
+[#] sysctl net.ipv4.conf.INTERFACE_NAME.rp_filter=1
+```
+
+Most Linux distributions default to Loose Reverse Path Forwarding. In strict mode, traffic from `172.30.1.1` on eth-02 would be dropped, as it should
+have routed through `eth-01`. This enforces a symmetrical routing policy but can disrupt asymmetric routing configurations. Loose Reverse Path Forwarding,
+conversely, processes traffic if routable through any interface.
+
+Why does this matter for WireGuard? A firewall's secondary set of rules ensures that strict reverse path forwarding operates accurately. The `fwmark` is
+set by the traffic traversing the reverse path, working in collaboration with Linux's conntrack subsystem, which persistently associates incoming traffic
+with its corresponding outgoing traffic [5]. The second rule sets the "connection mark" labeled `ct mark` as the `fwmark` during connection establishment,
+while the third rule copies it back when packets are received.
+
+`wg-quick` then instructs the kernel to use the `fwmark` for reverse path forwarding, since this is not enabled by default:
+
+```
+[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
+```
+
+[5] For example, in tracking a UDP stream, both IPs (source and destination) and L4 headers (source and destination ports) can be tracked to identify
+a connection.
+
+## Additional Thoughts
+
+When researching WireGuard and reading through the documentation, I found there were a few non-obvious
+technical details that seemed undocumented, although potentially important.
+
+### UDP Socket Parameters
+
+WireGuard permits users to modify the UDP port on which an interface listens using `ListenPort`. Although,
+it always binds its internal UDP socket to all available interfaces using `INADDR_ANY` [6]. This is an
+important consideration reasoning about packet flows and writing netfilter rules.
+
+### Broadcast and Multicast Traffic
+
+Broadcast and multicast traffic are used in standard protocols, notably service autodiscovery. When considering how
+to configure effective firewalls, I was led to ask whether WireGuard carried multicast traffic. Short answer: yes and
+no. If the multicast ip range `224.0.0.0/4` or `ff00::/8` appear in the `AllowedIPs` for the tunnel, multicast traffic
+could theoretically be broadcast from the other peer. Although, this works with at most two peers. Internally, WireGuard
+uses a single prefix tree to select the endpoint to which a packet is sent. If the same `AllowedIPs` appear within
+the configuration of multiple peers, the last peer configuration overwrites the routes configured on other peers [7].
+Thus Mutlicast traffic can be directed to, at most, one peer. Thus, if you want to pass broadcast or multicast traffic,
+a secondary encapsulation method must be used on top of WireGuard. This does not mean peers with default routes in their
+`AllowedIPs` may leak Multicast traffic. This seems to be technically possible.
+
+In practice, the interface flags are used by programs like `avahi` to determine on which interfaces they should broadcast [8].
+WireGuard is not started with the `IFF_MULTICAST` or `IFF_BROADCAST` flags [8]. According to comments in the Linux kernel,
+links without `IFF_MULTICAST` can perform multicast but point-to-point devices cannot broadcast [9]. The exact meaning of these
+flags seem ambiguous from the limited documentation, and I wouldn't be surprised if the kernel and userspace developers were
+on different pages as to their exact technical meaning.
+
+> `IFF_MULTICAST` means that this media uses special encapsulation for multicast frames. Apparently, all `IFF_POINTOPOINT` and
+`IFF_BROADCAST` devices are able to use multicasts too.
+>
+> \- [9]
+
+[6] [Kernel cGit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireguard/socket.c?id=e74216b8def3803e98ae536de78733e9d7f3b109#n361)
+    [Github](https://github.com/torvalds/linux/blob/89bf6209cad66214d3774dac86b6bbf2aec6a30d/drivers/net/wireguard/socket.c#L361)
+
+[7] [Github](https://github.com/lathiat/avahi/blob/55d783d9d11ced838d73a2757273c5f6958ccd5c/avahi-core/iface-linux.c#L104)
+
+[8] [Kernel cGit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireguard/device.c?id=b5cc3833f13ace75e26e3f7b51cd7b6da5e9cf17#n292)
+    [Github](https://github.com/torvalds/linux/blob/b5cc3833f13ace75e26e3f7b51cd7b6da5e9cf17/drivers/net/wireguard/device.c#L292)
+
+[9] [Kernel cGit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_link.h?id=706a741595047797872e669b3101429ab8d378ef#n423)
+    [Github](https://github.com/torvalds/linux/blob/706a741595047797872e669b3101429ab8d378ef/include/uapi/linux/if_link.h#L423)
+