Wireguard interface does not get IPv6 addresses assigned

iyzana · May 27, 2023, 12:31am

Hi, I'm having trouble getting OpenWrt to assign a IPv6 address to the wireguard interface.

When configuring an IPv6 address for a wireguard interface in UCI no IPv6 address actually shows up on the interface and net.ipv6.conf.wg0.disable_ipv6 = 1 is set.

ip addr show dev wg0 gives

35: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN qlen 1000
    link/[65534] 
    inet 10.122.122.1/24 brd 10.122.122.255 scope global wg0
       valid_lft forever preferred_lft forever

even though the wiregard config in /etc/config/network includes IPv6 addresses:

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '51820'
	option private_key 'redacted'
	list addresses 'fd3a:bb4f:add2:43c2::1/64'
	list addresses '10.122.122.1/24'

config wireguard_wg0
	option public_key 'redacted'
	option route_allowed_ips '1'
	option persistent_keepalive '25'
	option description 'phone'
	list allowed_ips '10.122.122.2/32'
	list allowed_ips 'fd3a:bb4f:add2:43c2::2/128'

config wireguard_wg0
	option public_key 'redacted'
	option route_allowed_ips '1'
	option persistent_keepalive '25'
	option description 'work'
	list allowed_ips '10.122.122.3/32'
	list allowed_ips 'fd3a:bb4f:add2:43c2::3/128'

And this is the wg0.conf that's automatically generated by OpenWrt when starting the wg0 interface:

[Interface]
PrivateKey=redacted
ListenPort=51820
[Peer]
PublicKey=redacted
AllowedIPs=10.122.122.2/32
AllowedIPs=fd3a:bb4f:add2:43c2::2/128
PersistentKeepalive=25
[Peer]
PublicKey=redacted
AllowedIPs=10.122.122.3/32
AllowedIPs=fd3a:bb4f:add2:43c2::3/128
PersistentKeepalive=25

Manually adding the IPv6 to the interface also does not work and gives the following error:

root@router:~# ip addr add fd3a:bb4f:add2:43c2::1/64 dev wg0
ip: RTNETLINK answers: Permission denied

This error occurs because the sysctl net.ipv6.conf.wg0.disable_ipv6 = 1 is set by OpenWrt. After manually setting net.ipv6.conf.wg0.disable_ipv6 to zero adding the IPv6 works, but by then the automatic setup of the IPv6 routes has already failed.

My question is why OpenWrt / uci / netifd would set this sysctl.

IPv6 connectivity in general works fine, the other interfaces don't have this sysctl set to 1, have IPv6 addresses assigned to them and can reach the IPv6 internet without problems. My question is not about IPv6 routing for wireguard though, I will figure that out afterwards.

Some info about my setup:

OpenWrt 22.03.5, r20134-5f15225c1e
MikroTik RouterBOARD 962UiGS-5HacT2HnT (hAP ac)
All packages up-to-date
kernel - 5.10.176-1-9c18dec290150de51248d40d851655cf
kmod-wireguard - 5.10.176-1
luci-app-wireguard - git-23.018.72712-6d712c3
luci-proto-wireguard - git-23.093.40597-18a1842
wireguard-tools - 1.0.20210424-3

lleachii · May 27, 2023, 9:44am

Wireguard does not have an IP auto assign feature

There are some threads about how to assign IPv6 address, though.

Even if it did, you disabled it

I'm confused, why do you expect to see an assigned IPv6 address when you knowingly disabled it?

NPeca75 · May 27, 2023, 9:53am

Hi

does other interfaces have IPv6 ?

ip -6 a

iyzana · May 27, 2023, 10:59am

@lleachii
Sorry, that sentence was badly worded. I never manually set that sysctl, it is automatically being set to that value by some OpenWrt system (I assume netifd is responsible for it) whenever I restart the wg0 interface.

What do you mean by "Wireguard does not have an IP auto assign feature"? The IPv4 address I specified in the UCI configuration is being automatically assigned to the interface, just not the IPv6 address.

@NPeca75
Yes, other interfaces have IPv6 addresses:

root@router:~# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f9dd:42ef:59fd:bcd5/64 scope link 
       valid_lft forever preferred_lft forever
7: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:a45:b47c:2364::1/64 scope global dynamic noprefixroute 
       valid_lft 214173sec preferred_lft 127773sec
    inet6 fd81:55be:299a:64::1/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::f75c:bee2:3d22:f54d/64 scope link 
       valid_lft forever preferred_lft forever
9: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:a45:b47c:2300::1/64 scope global dynamic noprefixroute 
       valid_lft 214173sec preferred_lft 127773sec
    inet6 fd81:55be:299a::1/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::f75c:bee2:3d22:f54c/64 scope link 
       valid_lft forever preferred_lft forever
11: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f75c:bee2:3d22:f54b/64 scope link 
       valid_lft forever preferred_lft forever
14: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f75c:bee2:3d22:f562/64 scope link 
       valid_lft forever preferred_lft forever
16: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f75c:bee2:3d22:f562/64 scope link 
       valid_lft forever preferred_lft forever
28: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f75c:bee2:3d22:f563/64 scope link 
       valid_lft forever preferred_lft forever
34: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 state UNKNOWN qlen 3
    inet6 2a01:a45:b47c:23da:7463:b598:97fe:a610/64 scope global dynamic noprefixroute 
       valid_lft 258562sec preferred_lft 172162sec
    inet6 fe80::557b:3bfe:7af4:ce33/128 scope link 
       valid_lft forever preferred_lft forever

lleachii · May 27, 2023, 11:01am

I would call that "manual" or "static" assignment - I think I merely misunderstood your terminology. My bad.

vgaetera · May 27, 2023, 12:42pm

It works for me by default, so check custom settings:

grep -r -e "ipv6.*disable" /etc
grep -r -v -e "^#" -e "^$" /etc/sysctl.*

iyzana · May 27, 2023, 1:36pm

grep -r -e "ipv6.*disable" /etc only has matches in /etc/init.d/miniupnpd and /etc/rc.d/S94miniupnpd which don't seem related to my problem.

grep -r -v -e "^#" -e "^$" /etc/sysctl.* gives the following output, which I believe is the default OpenWrt configuration:

/etc/sysctl.d/10-default.conf:kernel.panic=3
/etc/sysctl.d/10-default.conf:kernel.core_pattern=/tmp/%e.%t.%p.%s.core
/etc/sysctl.d/10-default.conf:fs.suid_dumpable=2
/etc/sysctl.d/10-default.conf:fs.protected_hardlinks=1
/etc/sysctl.d/10-default.conf:fs.protected_symlinks=1
/etc/sysctl.d/10-default.conf:net.core.bpf_jit_enable=1
/etc/sysctl.d/10-default.conf:net.ipv4.conf.default.arp_ignore=1
/etc/sysctl.d/10-default.conf:net.ipv4.conf.all.arp_ignore=1
/etc/sysctl.d/10-default.conf:net.ipv4.ip_forward=1
/etc/sysctl.d/10-default.conf:net.ipv4.icmp_echo_ignore_broadcasts=1
/etc/sysctl.d/10-default.conf:net.ipv4.icmp_ignore_bogus_error_responses=1
/etc/sysctl.d/10-default.conf:net.ipv4.igmp_max_memberships=100
/etc/sysctl.d/10-default.conf:net.ipv4.tcp_fin_timeout=30
/etc/sysctl.d/10-default.conf:net.ipv4.tcp_keepalive_time=120
/etc/sysctl.d/10-default.conf:net.ipv4.tcp_syncookies=1
/etc/sysctl.d/10-default.conf:net.ipv4.tcp_timestamps=1
/etc/sysctl.d/10-default.conf:net.ipv4.tcp_sack=1
/etc/sysctl.d/10-default.conf:net.ipv4.tcp_dsack=1
/etc/sysctl.d/10-default.conf:net.ipv6.conf.default.forwarding=1
/etc/sysctl.d/10-default.conf:net.ipv6.conf.all.forwarding=1
/etc/sysctl.d/11-nf-conntrack.conf:net.netfilter.nf_conntrack_acct=1
/etc/sysctl.d/11-nf-conntrack.conf:net.netfilter.nf_conntrack_checksum=0
/etc/sysctl.d/11-nf-conntrack.conf:net.netfilter.nf_conntrack_tcp_timeout_established=7440
/etc/sysctl.d/11-nf-conntrack.conf:net.netfilter.nf_conntrack_udp_timeout=60
/etc/sysctl.d/11-nf-conntrack.conf:net.netfilter.nf_conntrack_udp_timeout_stream=180

iyzana · May 27, 2023, 2:12pm

Some more information I gathered:

This is the output of logread when stopping and starting the wg0 interface:

ifdown wg0

Sat May 27 15:39:42 2023 daemon.notice netifd: Network device 'wg0' link is down
Sat May 27 15:39:42 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::a7d3:fd21:5669:a2cc%pppoe-wan: Address not available
Sat May 27 15:39:42 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::a7d3:fd21:5669:a2cc%pppoe-wan: Address not available
Sat May 27 15:39:42 2023 daemon.notice netifd: Interface 'wg0' is now down

ifup wg0

Sat May 27 15:40:07 2023 daemon.notice netifd: Interface 'wg0' is setting up now
Sat May 27 15:40:07 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::a7d3:fd21:5669:a2cc%pppoe-wan: Address not available
Sat May 27 15:40:07 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::a7d3:fd21:5669:a2cc%pppoe-wan: Address not available
Sat May 27 15:40:07 2023 daemon.notice netifd: Interface 'wg0' is now up
Sat May 27 15:40:07 2023 daemon.notice netifd: Network device 'wg0' link is up
Sat May 27 15:40:08 2023 user.notice firewall: Reloading firewall due to ifup of wg0 (wg0)

When the wg0 interface comes up a wireguard shell script at /lib/netifd/proto/wireguard.sh (which belongs to the wireguard-tools package) seems to be triggered which actually configures the interface, generates the wireguard config, applies it and then runs ubus call network.interface notify_proto with the following json body:

{
  "action": 0,
  "ifname": "wg0",
  "link-up": true,
  "keep": false,
  "ipaddr": [{ "ipaddr": "10.122.122.1", "mask": "24" }],
  "ip6addr": [{ "ipaddr": "fd3a:bb4f:add2:43c2::1", "mask": "64" }],
  "routes": [
    { "target": "10.122.122.2", "netmask": "32" },
    { "target": "10.122.122.3", "netmask": "32" }
  ],
  "routes6": [
    { "target": "fd3a:bb4f:add2:43c2::2", "netmask": "128" },
    { "target": "fd3a:bb4f:add2:43c2::3", "netmask": "128" }
  ],
  "interface": "wg0"
}

Immediately before this ubus call net.ipv6.conf.wg0.disable_ipv6 is still 0, but after the call it is 1. I don't know how to figure out who receives this call, but I assume it is netifd.

vgaetera · May 27, 2023, 2:35pm

I'm unable to reproduce the above issue on a freshly deployed KVM guest running the latest stable OpenWrt release.

Perhaps the cause of the problem is some additionally installed component introducing a conflicting setting or leading to a race condition.

You can check if the issue persists after performing back up, settings reset, and deploying the VPN with automated script.

iyzana · May 28, 2023, 12:50pm

Thanks for the tip to debug this by starting from the factory defaults. I found the cause of my problem and it was a configuration error in /etc/config/network. I had included the wg0 interface as a port in the br-lan bridge interface like this:

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'
	list ports 'wg0'

I am not sure when or why I did this or why that would cause this specific problem. This is the first time I ran into any troubles due to this. Simply removing list ports 'wg0' and running /etc/init.d/network restart solved the problem and IPv6 addresses are now successfully assigned to the wg0 interface.

system · June 7, 2023, 12:51pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.