Help with ipv6 configuration for router connected to wireguard tunnel

Hi,

I've flashed OpenWrt 18.06.2 to a netgear WNDR3800 and I have set it up with a wireguard tunnel according to this guide I found by directnupe:

nordvpn OpenWrt wireguard client

Everything works great, but for the computers on the lan I only have ipv4 connectivity.

If I SSH into the box then ipv6 works (I can ping -6 google), but it seems that somehow forwarding is not working properly. What do I need to do to fix this?

It seems to me that this link might be useful, but I'm not sure how to apply it to my case.

I've copied a few bits from my network and firewall config below:

/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 'fd76:5ae9:3110::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '192.168.10.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option ifname 'eth1'
	option proto 'dhcp'

config interface 'wan6'
	option ifname 'eth1'
	option proto 'dhcpv6'

config interface 'wg0'
	option proto 'wireguard'
	option private_key '**************************'
	list addresses '10.**.**.**/32'
	list addresses 'fc00:************************/128'
	option dns '193.**.**.**'

config wireguard_wg0
	option public_key '*****************************'
	option route_allowed_ips '1'
	list allowed_ips '0.0.0.0/0'
	list allowed_ips '::/0'
	option persistent_keepalive '25'
	option description 'WG'
	option endpoint_host '**.**.**.**'
	option endpoint_port '51820'

/etc/config/firewall:

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

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

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

How large IPv6 prefix do you get from nordvpn? For a LAN you need a /64 (or larger such as a /48) prefix which is required for SLAAC. I don't know if it's possible to add the prefix to the wg0 interface, but you can create a separate static interface and add it there anyway.

network.prefix_wg0=interface
network.prefix_wg0.proto='static'
network.prefix_wg0.ip6prefix='fc**:************************/**'
network.prefix_wg0.ifname='@loopback'

BTW they shouldn't use addresses beginning with "fc". They should use "fd" instead if they want to use non-global IPv6 addresses.

The block fc00::/8 is undefined.
The block fd00::/8 is defined for /48 prefixes, formed by setting the forty least-significant bits of the prefix to a randomly generated bit string. This results in the format fdxx:xxxx:xxxx:: for a prefix in this range. RFC 4193 offers a suggestion for generating the random identifier to obtain a minimum-quality result if the user does not have access to a good source of random numbers.
https://en.wikipedia.org/wiki/Unique_local_address

1 Like

You may want to give this article I wrote on using WireGuard on OpenWrt a look.

http://www.makikiweb.com/ipv6/wireguard_on_openwrt.html

1 Like
  • If you are only issued a /128, only the router will have IPv6.
  • The IP you have listed is private ULA IP anyways. It wouldn't have Internet connectivity.
1 Like

Thanks for your replies. Not sure if it matters, but the VPN here I am connecting to is Mullvad, not NordVPN.
I think the router at least has a public ip (the br-lan interface has an address fd::****/60). The /128 is just the ip address of the tunnel entry (I think). It also has a /32 ipv4 address.

root@OpenWrt:~# ip addr show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 2e:xx:xx:xx:xx:c4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::xxxx:xxxx:xxxx:a3c4/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 2c:xx:xx:xx:xx:c5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.25/24 brd 192.168.1.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::2exx:xxxx:xxxx:a3c5/64 scope link 
       valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2e:xx:xx:xx:xx:c4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd76:5ae9:3110::1a3/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::2cxx:xxxx:xxxx:a3c4/64 scope link 
       valid_lft forever preferred_lft forever
7: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 2e:xx:xx:xx:xx:c4 brd ff:ff:ff:ff:ff:ff
9: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 2c:xx:xx:xx:xx:c4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2exx:xxxx:xxxx:xxc4/64 scope link 
       valid_lft forever preferred_lft forever
11: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1
    link/none 
    inet 10.99.25.58/32 brd 255.255.255.255 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fc00:bbbb:xxxx:xxxx::xxxx/128 scope global 
       valid_lft forever preferred_lft forever
12: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 2c:xx:xx:xx:xx:c6 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2exx:xxxx:xxxx:xxc6/64 scope link 
       valid_lft forever preferred_lft forever

and from a computer on the wireless lan:

matt@lpad:~$ ip addr show wlp2s0 
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 44:xx:xx:xx:xx:44 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.147/24 brd 192.168.10.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 43116sec preferred_lft 43116sec
    inet6 fd76:5ae9:3110::62c/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd76:5ae9:3110:0:47c:dd4:e17a:da30/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::4e86:ae6b:da9d:da13/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Later I will have a look at the guide by cvmiller to see if I can get anywhere.
Thanks

A difference between IPv4 and IPv6 is that masquerade/NAT is usually not used with IPv6. (And it isn't supported by openwrt..) This means each device need its own ipv6 address from a prefix assigned by the provider. It is possible to use network prefix translation with openwrt but as the name implies its only the prefix that's translated. Which means each device still needs its own IPv6 address. But you could translate for example between the provider prefix and your ULA if you need.

BTW I assume tre provider uses IPv6 NAT or NTP to translate to a global IPv6 prefix.

1 Like

Those aren't public IPs. The fe80 is link-local; and the fd16 and fd76 are more ULAs.

If they issue an IPv6 address, it's likely a single /128.

BTW, @mattp, welcome to the community!

1 Like

A single (/128) address won't be enough for more than one host anyway since IPv6 masquerade isn't supported by openwrt. But a ULA prefix assigned by the VPN service provider should work if they apply NAT or NTP to the traffic destined for the internet.

2 Likes

OK, I think I get it now.

The wireguard server at the other end has assigned me a single ip address fc00:xxx/128, which probably should be in the fd::/8 range, but they did it wrong. But more importantly, it's a /128 and is impossible to subdivide further. So in order to route ipv6 traffic I would ideally need to be allocated a /60 or larger segment. Is that right?

I mistook the 'fd76:5ae9:3110::/48' for something to do with the wireguard interface, but it's ULA prefix that is set up in the router.

Thanks for your help.

1 Like

That is correct.

IPv6 masquerading is possible and limited IPv6 connectivity is still better than nothing.
For example you can find a simple NAT6 script here:
https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

2 Likes

Please don't do NAT66. NAT should not be a solution for IPv6.

If your VPN provider won't give you a /60, then use a different provider, such as ungleich which will happily give you a /48 on the end of a wireguard tunnel.

https://ungleich.ch/ipv6/vpn/

1 Like

Someone may want to use his own server in a suitable location but it is limited to a /64 prefix.

Of course there are always corner cases. But IPv6 with its vast address space allows us to create networks which do not include NAT. NAT was invented to conserve IPv4 address space. We shouldn't implement NAT in IPv6 networks, but find other ways, such as a hosting service which will give you more than a /64.

In an ideal world it is as you say, but in real life there are multiple corner use cases:

  • DNSv6 traffic interception for DNS hijacking.
  • IPv6 and DNSv6 traffic interception for Tor client.
  • IPv6 masquerading for dual-stack setup with no prefix, e.g. VPNs, VPSs, some ISPs, etc.

As you can see, NAT6 is not limited to masquerading.
And the provider/hosting may be already prepaid for several months/years in advance, or the only one that is suitable based on other parameters, so dropping it is unreasonable.
That's why broken NAT6 support is a huge mistake.

1 Like

VPSs and ISPs which don't provide you with a routed IPv6 prefix are a joke. Who thought it was a good idea to only provide a IPv6 prefix directly connected to the network interface?

Can't you use proxy NDP in this case? Similar to how you may use proxy ARP with ipv4 if you want to assign vpn clients ipv4 addresses in the LAN subnet.

We will have to agree to disagree. Of course NAT could be used in your scenarios, but it isn't the only answer.

For example, DNS hijacking. A why are you hijacking the client's use of DNS? Many Enterprises do this because they want to control where the user goes. You don't need to use NAT, you can merely block all TCP/UDP port 53 from the clients other than the corporate DNS servers. If the client chooses a different DNS service they won't go anywhere.

But even this doesn't stop the determined. Have you considered the client may be using SSH to create a SOCKS proxy on a remote machine. Your DNS hijacking won't stop that. What if a determined person comes in with their own really large host file, which allows them to go anywhere they want to go. Your DNS hijacking won't stop that.

NAT breaks the network in many ways. A key one is end to end connectivity, but also non-reputability. When you have end to end connectivity, you know who connected to who.

If your VPN/VPS/ISP provider won't give you more than a /64, then get another, there are alternatives. As I pointed out earlier, Ungleich will give you a /48 on a Wireguard tunnel.