aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--content/blog/kubernetes/k3s-ipv6-outgoing-nat.md1
-rw-r--r--content/blog/kubernetes/k3s-ipv6.md1
-rw-r--r--content/blog/miscellaneous/wireguard-ipv6.md65
-rw-r--r--content/blog/miscellaneous/wireguard-routing-2.md2
4 files changed, 68 insertions, 1 deletions
diff --git a/content/blog/kubernetes/k3s-ipv6-outgoing-nat.md b/content/blog/kubernetes/k3s-ipv6-outgoing-nat.md
index 231c5f6..6e20ebd 100644
--- a/content/blog/kubernetes/k3s-ipv6-outgoing-nat.md
+++ b/content/blog/kubernetes/k3s-ipv6-outgoing-nat.md
@@ -3,6 +3,7 @@ title: Calico and outgoing ipv6 traffic on k3s
date: 2022-01-23
description: By default calico does not nat outgoing ipv6 traffic
tags:
+ - ipv6
- k3s
- kubernetes
---
diff --git a/content/blog/kubernetes/k3s-ipv6.md b/content/blog/kubernetes/k3s-ipv6.md
index 8e01385..f30b7a5 100644
--- a/content/blog/kubernetes/k3s-ipv6.md
+++ b/content/blog/kubernetes/k3s-ipv6.md
@@ -3,6 +3,7 @@ title: Making dual stack ipv6 work with k3s
date: 2021-07-27
description: How to setup a working ipv4/ipv6 service on k3s
tags:
+ - ipv6
- k3s
- kubernetes
---
diff --git a/content/blog/miscellaneous/wireguard-ipv6.md b/content/blog/miscellaneous/wireguard-ipv6.md
new file mode 100644
index 0000000..eb5413f
--- /dev/null
+++ b/content/blog/miscellaneous/wireguard-ipv6.md
@@ -0,0 +1,65 @@
+---
+title: Wireguard and ipv6
+description: "An overview of ipv6 with wireguard: it just works"
+date: 2023-02-28
+tag:
+- ipv6
+- vpn
+- wireguard
+---
+
+## Introduction
+
+In the previous articles I voluntarily omitted to configure ipv6 in order to simplify the examples, let's cover it now.
+
+## Connecting to wireguard over ipv6
+
+This one is easy, just specify an ipv6 endpoint in your peer's configuration:
+```cfg
+[Interface]
+PrivateKey = <private-key>
+ListenPort = 342
+Address = 10.1.2.10/32
+
+[Peer]
+PublicKey = <public-key>
+Endpoint = [2a01:4f8:c2c:bcb1::1]:342
+AllowedIPs = 10.1.2.0/24
+PersistentKeepalive = 60
+```
+
+## Running ipv6 traffic through wireguard
+
+For simplicity I revert the endpoint to an ipv4 address in the next examples. It could be an ipv6 address but I want to show you that it is possible to combine settings any way you want.
+
+`fd00::/8` is reserved for private ipv6 addressing, I am therefore using it in several places and you can too:
+```cfg
+[Interface]
+PrivateKey = <private-key>
+ListenPort = 342
+Address = fd00::2/128
+
+[Peer]
+PublicKey = <public-key>
+Endpoint = 168.119.114.183:342
+AllowedIPs = fd00::1/128
+PersistentKeepalive = 60
+```
+
+The routing table will be populated in the same fashion as with ipv4 traffic, the same rules we already saw apply in the very same way. Here I shared two `/128` subnets but any subnet size would do as long as you are careful with what you are doing.
+
+To have both ipv4 or ipv6 traffic, separate the routes with a comma:
+```cfg
+[Interface]
+PrivateKey = <private-key>
+ListenPort = 342
+Address = 10.1.2.10/32, fd00::2/128
+
+[Peer]
+PublicKey = <public-key>
+Endpoint = 168.119.114.183:342
+AllowedIPs = 10.1.2.9/32, fd00::1/128
+PersistentKeepalive = 60
+```
+
+We can also use public ipv6 addressing, for example to provide ipv6 connectivity to a host whose ISP does not offer it yet (yes, this still happens in 2023!). I will cover this in a next article about this special case of routing all internet traffic through wireguard. \ No newline at end of file
diff --git a/content/blog/miscellaneous/wireguard-routing-2.md b/content/blog/miscellaneous/wireguard-routing-2.md
index ff8aba1..a4e8ec5 100644
--- a/content/blog/miscellaneous/wireguard-routing-2.md
+++ b/content/blog/miscellaneous/wireguard-routing-2.md
@@ -129,7 +129,7 @@ AllowedIPs = 10.1.2.3/32
You might have feared this would be the most complicated configuration but it is the simplest: every peer has a `/32` netmask. The only thing to note is that we do not specify an endpoint for Adolin and Baon since they are behind a home network's NAT.
-The only additional thing we need is to enable routing on Elend so that it can forward traffic (firewalling is the subject of the next article). This can be done by setting the right sysctl value depending on your operating system:
+The only additional thing we need is to enable routing on Elend so that it can forward traffic (firewalling is the subject of a next article). This can be done by setting the right sysctl value depending on your operating system:
- FreeBSD: set `gateway_enable="YES"` in your `/etc/rc.conf`
- Linux: set `net.ipv4.ip_forward=1` in your `/etc/sysctl.conf`
- OpenBSD: set `net.inet.ip.forwarding=1` in your `/etc/sysctl.conf`