[SOLVED Wow!] Strange Issues With RA/DHCPv6 and odhcp on guest network

Hello everyone:
I think I am in a big trouble: After countless trying over past 2 weeks, I still can't get IPv6 working properly on my guest network. I read a lot of articles with the topics of Router Advertisements / ICMPv6, DHCPv6 and openwrt UCI firewall etc. Tried a lot of setting combinations. Current configuration seems alright, IPv4 is working perfectly on both interfaces and their clients. The interfaces themselves seem to have valid IPv6 address and running stable. These clients connected to interface 'lan' will having a working and stable IPv6 connection, but it's not the case for those clients connected to interface 'guest': Those clients will 'lost' their IPv6 connection after several minutes... (I'm testing with https://test-ipv6.com )

I made a simple table to describe the connection status:

RA only: means to enable Router Advertisements without DHCPv6
DHCPv6 only: means to enable DHCPv6 with option stateless and statefull
Stable: clients will have a stable IPv6 connection
No: clients won't get any IPv6 connections
Unstable: clients will have a unstable IPv6 connection
?: Not well tested.

clients connected to lan via WiFi:

**RA only: 
android 8 Stable
android 6 Stable
PC (windows 10) Stable
PC (Windows 7) Stable
PC (Fedora 28) Stable

**DHCPv6 only: 
android 8 No
android 6 No
PC (windows 10) No
PC (Windows 7) No
PC (Fedora 28) No

clients connected to guest via WiFi:

**RA only: 
android 8 No
android 6 Stable?
PC (windows 10) Stable
PC (Windows 7) No
PC (Fedora 28) Unstable

**DHCPv6 only: 
android 8 No
android 6 No
PC (windows 10) No
PC (Windows 7) No
PC (Fedora 28) No

So the conclusion is: RA is working well on lan, RA is unstable on guest. DHCPv6 server is NOT enabled on both interface.

I know the odhcp6 is the DHCPv6 server for openwrt/LEDE, I checked the log and found outputs from odhcp. So I don't see any reasons why DHCPv6 server won't work. Is this a BUG? Can Someone try to use DHCPv6 only option with LEDE 17.1.4 and tell me the result?
PS: version of odhcpd: odhcpd - 2017-10-02-c6f3d5d4-2, also tried 2018-03-02-2da5850f-3.

I must admit that this is something exceed my ability, I can't describe how frustrated I was with these days. Any help or suggestions are highly appreciated!


My router is a 2.4/5Ghz dual band WiFi router, the LEDE version is 17.1.04, with default software plus 6in4 package installed. It's using PPPoE to get an IPv4-only address from ISP. I'm using 6in4 provider 'tunnelbroker.net' to get an IPv6 connection.

My interface configurations are like this:

wan: PPPoE to my ISP
wan6: DHCPv6 (not enabled, and will not function because ISP not providing IPv6)
henet: 6in4 protocol
lan: main WiFi network (IPv6 is working perfectly here)
guest: for guests connect with WiFi (clients' IPv6 connection unstable)

Below are my configuration files:

/etc/config/wireless

// partial contents omitted

config wifi-iface
	option device 'radio0'
	option mode 'ap'
	option encryption 'psk2+ccmp'
	option key 'Magical Words'
	option network 'guest'
	option ssid 'Rainbow'
	option hidden '1'
	option isolate '1'

config wifi-iface
	option device 'radio1'
	option mode 'ap'
	option encryption 'psk2+ccmp'
	option key 'Magical Words'
	option network 'guest'
	option ssid 'Rainbow_5G'
	option hidden '1'
	option isolate '1'

/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '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 localservice '1'
	option nonwildcard '0'
	option sequential_ip '1'
	option dhcpleasemax '40'
	option cachesize '1500'
	option noresolv '1'
	option nohosts '1'
	list server '127.0.0.1#1053'
	list server '/1.pool.ntp.org/8.8.4.4'
	list server '/north-america.pool.ntp.org/8.8.4.4'
	list server '/1.fedora.pool.ntp.org/8.8.4.4'
	list server '/pool.ntp.org/149.112.112.112'
	list server '/1.europe.pool.ntp.org/149.112.112.112'

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

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'

config dhcp 'guest'
	option interface 'guest'
	option leasetime '24h'
	option start '20'
	option limit '14'
	option ra 'server'
	option ra_management '1'
	option dhcpv6 'server'

/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 interface 'wan'
	option ifname 'eth0.2'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'pppoe'
	option username 'acc'
	option password 'pass'
	option ipv6 'auto'
	option peerdns '0'
	option dns '8.8.4.4 149.112.112.112 64.6.64.6 84.200.69.80 109.69.8.51 64.6.65.6 84.200.70.40 8.8.8.8'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option auto '0'
	option reqaddress 'try'
	option reqprefix 'auto'

config interface 'henet'
	option proto '6in4'
	option username 'mows'
	option peeraddr '1.2.3.4'
	option ip6addr '2001:123:c:1234::2/64'
	option ip6prefix '2001:123:1234::/48'
	option tunnelid '123456'
	option password 'RefreshKey'

config globals 'globals'
	option ula_prefix 'fdb2:1234:5678::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.9.1'
	option macaddr 'removed'
	option ip6assign '64'

config device 'lan_dev'
	option name 'eth0.1'
	option macaddr 'removed'

config interface 'guest'
	option type 'bridge'
	option _orig_ifname 'radio0.network2 radio1.network2'
	option _orig_bridge 'true'
	option proto 'static'
	option ifname 'eth0.3'
	option macaddr 'removed'
	option netmask '255.255.255.0'
	option ipaddr '192.168.10.1'
	option ip6assign '64'
	option ip6hint '1'

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

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

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4 6t'
	option vid '2'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '1 6t'

/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'

config zone
	option name 'wan'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6 henet'
	option input 'DROP'
	option forward 'DROP'

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

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 redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '51000-51999'
	option dest_port '51000-51999'
	option name 'PC'
	option dest_ip '192.168.9.10'

config include
	option path '/etc/firewall.user'
// PS: nothing in '/etc/firewall.user'

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

config forwarding
	option dest 'wan'
	option src 'guest'

config rule
	option name 'Allow Protocol 41'
	option src 'wan'
	option target 'ACCEPT'
	option proto '41'

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

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

config rule
	option target 'ACCEPT'
	option family 'ipv4'
	option proto 'tcp udp'
	option dest_port '53'
	option name 'Guest DNS'
	option src 'guest'

config rule
	option target 'ACCEPT'
	option family 'ipv4'
	option src 'guest'
	option name 'Guest DHCP'
	option dest_port '67-68'
	option proto 'udp'

config rule
	option target 'ACCEPT'
	option family 'ipv6'
	option src 'guest'
	option name 'Guest DHCPv6'
	option proto 'all'
	option dest_port '547'

config rule
	option target 'ACCEPT'
	option family 'ipv6'
	option name 'Guest IPv6 ICMP input icmp'
	option src 'guest'
	option proto 'icmp'

config rule
	option target 'ACCEPT'
	option family 'ipv6'
	option name 'Guest IPv6 ICMP input ipv6-icmp'
	option src 'guest'
	option proto 'ipv6-icmp'
// I'm not sure which one to use: IPv6 + 'icmp' or IPv6 + 'ipv6-icmp' ?

config rule
	option target 'ACCEPT'
	option family 'ipv4'
	option name 'Guest IPv4 ICMP input'
	option src 'guest'
	option proto 'icmp'

The only difference I see in your config between mine, is that I assign each local network an IPv6 IP from the /64 I wish it to possess. This /64 assignment must be allocated by you from the /48 assigned from HE.

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.xxx.1'
	option ip6addr '2001:xxxx:xxxx:xxxA::1/64'
	option ip6prefix '2001:xxxx:xxxx:xxxA::/64'

config interface 'network2'
	option proto 'static'
	option type 'bridge'
	option ifname 'eth0.3'
	option netmask '255.255.255.0'
	option ipaddr '192.168.xxx.1'
	option ip6addr '2001:xxxx:xxxx:xxxB::1/64'
	option ip6prefix '2001:xxxx:xxxx:xxxB::/64'

I see you have an Accept Ping on WAN rule, this must remain enabled for the HE tunnel checker to verify the tunnel, if you ever wish to block Ping, reference the HE wiki or your Tunnel Control Panel for the checker's IP address to allow.

Lastly, I tell DHCP to hand out via RA the router's IPv6 Link-Local IP for DNS.

1 Like

@lleachii
Thanks for your detailed reply!

I did allocated two /64 ipv6 address blocks from my /48 address pool.
The only thing different here is I was using option ip6hint '1' on interface guest instead of 'ip6addr' and 'ip6prefix' to automatic allocate global ip and link local address. But in theory, these settings from us should be identical.

Mine are looking like this:

IPv6 routed prefix: 2001:1234:1234::/48
ULA prefix: fdb2:1234:1234::/48

I was using /48 prefixes to both routed prefix and ula prefix, so I should have plenty of /64 global IPv6 addresses and link local addresses.

Also, because I was setting ip6hint to 1, so both global / local ipv6 addresses of guest interface should add ::1:0000:0000:0000:0000 compare to lan interface.

Global address for lan: 2001:1234:1234::1/64, 
Global address for guest: 2001:1234:1234:1::1/64 . 

Link local address for lan: fdb2:1234:1234::1/64
Link local address for guest: fdb2:1234:1234:1::1/64

Everything including my PC and my android phones are working perfectly on lan, but with guest, that's much different situation.

I thought the problem may come from the wifi setting isolate='1', but disable this won't help. Then I tried to change the firewall settings, I changed the rules for guest as same as lan like this:

/etc/config/firewall


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

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

and reload my firewall rules with command: /etc/init.d/firewall reload
But still without luck, the clients of guest interface will lost their IPv6 connections after several minutes.

And from these IPv6 articles, I found Router Advertisements(RA) and DHCPv6 are crucial to IPv6. So in theory, even there is only one of them can working properly, there will be no problem with IPv6 for these clients on guest network. So I enabled both them on both interface like this:

/etc/config/network


config dhcp 'guest'
	option interface 'guest'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'

config dhcp 'lan'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'

Add firewall rule for DHCPv6 on guest network:


config rule
	option target 'ACCEPT'
	option family 'ipv6'
	option src 'guest'
	option name 'Guest DHCPv6'
	option proto 'all'
	option dest_port '547'

And I also learned the ICMPv6 protocol is crucial to Router Advertisements(RA), so I put following rules to allow it:

config rule
	option target 'ACCEPT'
	option family 'ipv6'
	option name 'Guest IPv6 ICMP input'
	option src 'guest'
	option proto 'icmp'

I also checked the firewall settings of windows7/10 PC, they both enabled "Windows Core Networking" by default.(Windows Core Networking rule contains rules for ICMP and IPv4/IPv6 etc)
Oh, forgive me for this lengthy mass, I really have no idea on this now.
You can see it from this picture, guest interface do has a stable IPv6 connection, but it's clients are not.

image

Please allow me to ask more questions.

  1. Should I allow wan -> guest ping or ICMP / ICMP v6 protocols? I mean do the tunnel providers need to ping these clients?
  2. I'm not sure your meaning of this words: Lastly, I tell DHCP to hand out via RA the router’s IPv6 Link-Local IP for DNS.
    How to do this? Is there any DHCPv6 options or it's the firewall stuff?

Thanks in advance!

Under Interfaces > LAN > DHCP Server section > Ipv6 tab > Announced DNS Servers

But I'd recommend against the link-layer address, as this is ambiguous for any device having more than one link (like a desktop computer that has say two NICs) This is the kind of thing that ULA addresses are used for. I announce my router DNS as a ULA address, and it works well.

1 Like

@dlakelan
Hello, Many Thanks to you!
I think my DNS configurations are same as yours, and it's working well on the interface lan.
Just curious: May I know if you are using DHCPv6 alone or RA(SLAAC)?
Have a nice day!

I'm actually using RA/SLAAC the router runs Debian with dnsmasq so it's not LEDE, but it's the same concept.

Question for you, are your clients primarily Android phones? Can you test a desktop computer client wired? does it have the same issue with losing ipv6 connectivity?

Android phones are... shall we say... less than great with ipv6. They won't use DHCPv6 at all, and due to power saving settings many of them on older versions of Android ignore the multicast router advertisements during wifi sleep, and then lose their connections.

1 Like

@dlakelan
Hello, My clients are all wireless, including PCs and Android phones, and there are more phones on Guest network.
I have already tested many PCs to guest network via WiFi. Now I'll try to connect my notebooks with wired connection. but it may take more than 30 minutes for client(s) to 'lost' their IPv6 connection. :sweat_smile:

Update1:
It's kinda quicker than I thought:
After plug cable into port 2 (port 1 for lan, port 2 for guest), linux notebook and windows 7 notebook got an IPv4 only link. so this is something different to connect with WiFi:

clients connected to lan via WiFi:

**RA only: 
android 8 Stable
android 6 Stable
PC (windows 10) Stable
PC (Windows 7) Stable
PC (Fedora 28) Stable

**DHCPv6 only: 
android 8 No
android 6 No
PC (windows 10) No
PC (Windows 7) No
PC (Fedora 28) No

clients connected to guest via WiFi:

**RA only: 
android 8 No
android 6 Stable?
PC (windows 10) Stable
PC (Windows 7) No
PC (Fedora 28) Unstable

**DHCPv6 only: 
android 8 No
android 6 No
PC (windows 10) No
PC (Windows 7) No
PC (Fedora 28) No

I do remember I assigned port 2 to 'guest' with proper vlan id.(0.3) , but despite I enabled both RA and DHCPv6 on guest, the port 2 perform worse than WiFi. If connect via WiFi, the RA on guest is in a 'partial' working state. This is so weird.

Update2: Also tested port 1(lan interface), no IPv6 connection.

All wired ports have no IPv6 connections.

Hmmm, a properly operating IPv6 stack keeps track of not only the address, but the link as well. There shouldn't be a problem with, for example, defining all your gateway addresses as fe80::1 on every single link, as it is unique on the link.

I honestly don't know, but what happens when a desktop machine, say Ubuntu or MacOS, is connected to two networks, one of which on eth0 which advertises fe80::1 as DNS and one of which on wlan0 which advertises say fe80::2 (or fe80::1 even)

what DNS will it use :wink:

EDIT: or on two wired links... it's not that I think this wont' work, it's that I have no idea whether it works, and I've got a pretty good idea that the ULA won't be ambiguous

EDIT2: I kinda imagine the possibility that the DNS bounces back and forth slightly randomly between the two links, and actually that this might have nothing to do with link-local vs ULA, it's just that the OS can't necessarily decide who it should believe about what the DNS should be... one issue is that this might be true with link-local addresses even without the address number changing whereas if you use ULA you'll at least see /etc/resolv.conf or something changing what it has in it and be able to tell what's going on.

The choice of route, DNS, or other services is up to the host machine. It is no different than IPv4 in that way. The IPv6 stack keeps track of the combination of link-local address and link, revealing it in human-readable form as something like fe80::1%eth0 and fe80::1%eth1. Generally it can be specified as such in routing commands and configuration files as well.

Right, so what actually happens in real world deployments? What is the policy for Ubuntu, MacOS, and Windows?

I wonder if I advertise fe80::1 will I see /etc/resolv.conf have fe80::1%eth0 in it on say Debian or Ubuntu? What about when you're using NetworkManager vs when you're not... how does MacOS handle this? etc

My concern is not that it won't work, but more like it will potentially lead to ambiguity for the user as to what's going on if something doesn't report the link explicitly (even if it's say keeping track of the link in the underbelly of the OS).

The point of ULA is that if you're doing it right (generating a random one) then it should be unambiguously unique for all the links any given device is connected to, and that has advantages for people (rather than for the OS) during debugging and configuration.

Works fine and unambiguously in macOS

fe80::1%lo0                             link#1                          UHLI            lo0
fe80::1%vlan1                           0.d.b9.48.4c.d9                 UHLWIi        vlan1

Like the convention of the .1 being the router on a subnet in IPv4, I can immediately see traffic to fe80:1 on a link and know that it's intended for the gateway without a "magic decoder ring", as well as much more easily maintain firewall and monitoring configurations.

I would expect to see it in routing tables and soforth, and it makes good sense there, but what about in DNS? Usually computers don't use different DNS for different links, so if two links are advertising DNS at fe80::1 what happens in the DNS settings on each OS, and more to the point is it the same because it would be super annoying to have it work unambiguously on say MacOS, work but bounce back and forth on Debian/Ubuntu, and say work intermittently on Windows...

This is one of those questions that needs a lab :wink:

Anyway, for the moment I'll change my statement: I use ULAs for DNS and they work well for me, probably the link local address works too.

1 Like

@lleachii @dlakelan @jeff

Thank you for your help and discussions full of wisdom. I learned many things from this. You guys are cool!

And I should say never try to use the option ip6hint in this situation, it only made things worse.(though it's the default and recommended behavior)
Do use ip6addr/ip6prefix to manually allocate a /64 subnet will be sufficient. Although my wired ports still provide IPv4 only connections, and I haven't test my IPv6 network thoroughly. But I should mark this thread as SOLVED.
And finally, Have a nice day! :star_struck:

1 Like

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