Wireguard and IPv6

Briefly, in my home network, how do I set up a Wirgeguard interface such that both IPv4 and IPv6 traffic go through it?

I am using a Linksys WRT1900ACS as my home router, starting with the davidc502 build and adding the wireguard package. I have an ISP that supports IPv6. I am using Mullvad, which also supports IPv6. When I go through the Mullvad setup instructions for Wireguard on an OpenWrt router (https://mullvad.net/en/guides/running-wireguard-router/) , I receive both an IPv4 and IPv6 address from Mullvad for use in setting up the Wireguard network interface. I use them in the configuration for the network interface:

	list addresses '<IPv4 address not shown>/32'
	list addresses '<IPv6 address not shown>/128'

I also use both 0.0.0.0/0 and ::/0 as allowed_ips.

The Wireguard interface comes up and I get both a new external IPv4 address as a result but my IPv6 address stays the same, as shown by a visit to www.whatismyipaddress.com. wg show on the router shows a peer endpoint IPv4 address and both allowed_ips that I just described:

peer: <removed>
endpoint: 195.206.104.98:51820
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 1 minute, 45 seconds ago
transfer: 1.22 GiB received, 3.29 GiB sent
persistent keepalive: every 25 seconds

The Status Overview on the LuCI GUI shows the new IPv4 Upstream resulting from the Wireguard interface and also shows a new IPv6 Upstream resulting from Wireguard.

So, I'm assuming all the IPv6 traffic leaving my home network is unencrypted and only the IPv4 traffic is encrypted (I'm not yet skilled with Wireshark enough to prove that, however) largely because my external IPv6 address didn't change.

Thank you for making it through my lengthy question. What should I do? Or what additional guide can I read?

You should ask mullvad to give you a /60 allocation so you can give ipv6 to your network, not just your router

dlakelan,

Ah, thank you. You just taught me that Mullvad has given me a single IPv6 address and given we don't do NAT for IPv6, that's why I have the problem I do. Thanks!

I think most of these VPN providers think you will connect from say one single windows machine, so if they give out one single (private) ipv4 and one single ipv6 you'll be all set. Not so much in the case of people here on OpenWrt forum, who are trying to set up things for a network of at least tens of devices if not up to say 100.

My suspicion is that most VPN providers don't give out subnets. Though they should, it'd be easy for them to get a /32 allocation and divide it into /60's that'd be 2^28 customers ~ 250 Million they could handle

The providers need to catch up with the times. We are now near the end of the second decade of the 21st century so you'd expect many households to have more than a single computer that they'd want behind a VPN; especially with all the privacy issues discussed in the press over the course of the last year here in the States.

I've been poking around VPN services. Of the VPNs that do IPv6, of which I have only found a couple, Mullvad apparently provides a single IPv6 however AzireVPN appears to provide a subnet judging from the Wireguard instructions (https://www.azirevpn.com/support/guides/router/openwrt/wireguard). I will e-mail then to be sure.

I've thought about setting my up my own Wireguard server, hosting on DigitalOcean or some such service. I just haven't been 'brave' enough to take that plunge.

Honestly this is a pretty good method, but you should share the service with about 100 friends to get any anonymity.

It's not that hard to set up though.

Yea, I did find Algo on Github (https://github.com/trailofbits/algo) which appears to make it very straightforward to set up a Wireguard VPN server on a cloud hosting provider. However, I'm not interested in organizing a group effort. That said, I'm still fine tuning my "threat model" in terms of what I care about. I'm primarily irritated that my ISP and search engines can monetize my household's travels through the internet. I think a single-user cloud hosted VPN may treat that irritation but feel free to tell me if I have that wrong.

For now, I'll try to get Mullvad to give me a IPv6 subnet, and if that doesn't work out I'll give AzireVPN a try. Privacy and anonymity in the digital age can be a tough business.

I think it will keep your ISP from knowing what's up, but I doubt that it will do much for search engines. You could perhaps browse in incognito mode for all websites and that might help. It's Facebook and Google and maybe Twitter and their subsidiaries (advertising groups) that can still collect your data based on cookies and behavior and reporting back to them by the people who run ads on their websites, etc that isn't really helped in any way by VPN.

VPN is a great way to enhance security for command and control stuff (like. you want to log into your home NAS from remote locations) but it's really just an encrypted tunnel between two points. Once your traffic hits the end site and loads the web page, the web page has a fair amount of data about you probably.

The web is pretty useless if you turn off all Javascript and run in incognito mode and never log into any website and shut down and re-start your browser each time you switch to a different site... and that's the kind of stuff you need to do to really thwart tracking by FB, Google, and their ad revenue seekers.

VPN is also pretty great for getting around censorship, like China's great firewall and Iranian censors etc... it tunnels your traffic out to where the censors/ISP has no ability to see what site you're requesting. So that's a reasonable use-case as well.

Hm, I thought a VPN also helped with anonymity and search, in that the search request is actually going to Google from my VPN server rather than my IP address hence providing anonymity for search as well. Yes, I still understand Google has the search data, but they don't have my IP address tied to it.

I was unhappy about DNS and set up DNS-over-TLS using getdns and stubby using DNS privacy resolvers in order to encrypt my DNS requests. So I thought I was doing pretty good using both a VPN connection and DNS-over-TLS in terms of maintaining some semblance of privacy and anonymity.

I'm really not trying to go overboard because admittedly the use of the web in our house is pretty boring and standard fare. But since I have a bit of skill with Linux and with open source firmware on routers I want to take some logical steps.

Tracking is much more about cookies and JavaScript than about IP addresses these days. They identify your browser rather than your machine. So yes it does hide your IP address so if you are concerned about say an angry message board admin using your IP to geolocate you and call in a fake SWAT call on your house... Yes.

Hmph. You've shaken my faith in that the time I'm putting into using a VPN and setting up DNS-over-TLS may actually be worth relatively little. I'll need to read further to best understand if I'm better off directing my energy elsewhere.

It's good to think about what threat you are concerned about. Try opening your browser and looking at all the cookies it has. Those are there even with VPN.

Back to the original question...
Here's my setup:

  • Algo instance in the cloud
  • Wireguard on my OpenWRT router (wguk interface) connects to Algo
    • wguk is in wan firewall zone
  • wifi using subnet (wifivpn interface, 192.168.2.1/24)
    • firewall zone wifivpn > lan, wan
  • vpn-policy-routing sends 192.168.2.1/24 to wguk

This works great for IPv4. Any client on the wifi gets routed through the VPN. However, I haven't had any luck making it work for IPv6 as well. Algo assigned fd9d:bc11:4021::b/48 to the peer. Any clue how I can have wifivpn clients obtain v6 IPs and get routed through the tunnel?

I would really appreciate some help, because any resources I found so far were above my level of understanding.

/etc/config/network

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd3d:bb21:19a0::/48'

config interface 'lan'
option type 'bridge'
option ifname 'eth1.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'

config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
option peerdns '0'
option dns '9.9.9.9 149.112.112.112'

config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option peerdns '0'
option dns '2620:fe::fe 2620:fe::9'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '2 3 4 5 0t'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 6t'

config interface 'wguk'
option proto 'wireguard'
option private_key 'REDACTED'
list addresses '10.19.49.11/24'
list addresses 'fd9d:bc11:4021::b/48'

config wireguard_wguk
option public_key 'REDACTED'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::/0'
option endpoint_host 'REDACTED'
option endpoint_port '51820'
option persistent_keepalive '25'
option preshared_key 'REDACTED'

config interface 'wifivpn'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option type 'bridge'

config interface 'wgserver'
option proto 'wireguard'
option private_key 'REDACTED'
option listen_port 'REDACTED'
list addresses '192.168.77.1/24'

config wireguard_wgserver
option public_key 'REDACTED'
option persistent_keepalive '25'
list allowed_ips '192.168.77.77/32'
option description 'Thomas Phone'

config wireguard_wgserver
option public_key 'REDACTED'
list allowed_ips '192.168.77.78/32'
option persistent_keepalive '25'
option description 'Thomas PC'

/etc/config/firewall

config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'

config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan wgserver lan6'

config zone
option name 'wifivpn'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option network 'wifivpn'

config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wguk wan wan6'

config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'

config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'

config include
option path '/etc/firewall.user'

config forwarding
option dest 'wan'
option src 'lan'

config forwarding
option src 'wifivpn'
option dest 'wan'

config forwarding
option src 'lan'
option dest 'wifivpn'

config forwarding
option src 'wifivpn'
option dest 'lan'

config rule
option src '*'
option target 'ACCEPT'
option proto 'udp'
option dest_port 'REDACTED'
option name 'Allow-Wireguard-Inbound'

/etc/config/dhcp

config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
list server '9.9.9.9'
list server '149.112.112.112'
list server '2620:fe::fe'
list server '2620:fe::9'

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ra_management '1'

config dhcp 'wifivpn'
option interface 'wifivpn'
option start '100'
option limit '150'
option leasetime '12h'

config dhcp 'wan'
option interface 'wan'
option ignore '1'

config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'

to route globally they will need global ipv6 addresses. you only mention ULA addresses

To add an IPv6 prefix with OpenWrt you use the ip6prefix option, but I don't know if it's supported by openwrt wireguard proto otherwise you need to create a static alias interface.

Apparently same for everybody which use the default configuration. You should use your own ULA.

Algo seems to be using NAT66.

Well, devices that don't have global addresses will not initiate connections to global addresses using their ULA since OSes know that ULAs don't route. so even if someone in the loop does NAT66 it won't work.

Are you saying a RFC requires or recommends this behaviour? Are you thinking about particular OSes? Linux allows connecting to global IPv6 addresses from ULAs anyway. Though NAT66 is something that should be avoided. Network prefix translation is better if you can't assign global addresses directly to the hosts.

From https://tools.ietf.org/html/rfc4193 -

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications [IPV6]. These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6 addresses. They are not expected to be routable on the global Internet. They are routable inside of a more limited area such as a site. They may also be routed between a limited set of sites.

Really?

Are these global IPv6 address on site?

there's also the RFC for source address selection. i don't remember the number offhand

Yes, using ULA with IPv6-to-IPv6 Network Prefix Translation with internet access is a common scenario refer to RFC 6296.

1 Like