IPv6 Troubles - OpenWrt behind a FritzBox

zacharyrs · March 28, 2020, 11:50am

I have a Mi Router 3 Pro (Z), flashed with a custom build of OpenWrt, sitting behind a FritzBox (FB). My desktop (DT) is connected to the Mi.

For some reason, I can't access any websites over IPv6.
In particular, ping -6 ipv6.google.com from DT fails, as does ping6 ipv6.google.com from Z.
Additionally, running traceroute ipv6.google.com gives the following (censored a bit):

traceroute to ipv6.google.com (2404:6800:4006:803::200e), 30 hops max, 64 byte packets
 1  ???? (XXXX:XXXX:YYYY:fe00:DDDD:DDDD:DDDD:12ce)  1.041 ms  0.517 ms  0.573 ms
 2  *  *  *

I can ping between Z and DT without issue, and can ping to FB from Z and DT - it seems the issue is only outward?

The IPv6 addresses of all relevant devices are included below but censored slightly.

IPv6 Addresses

The patterns in uppercase (e.g. XXXX:XXXX) are all constants throughout all addresses.

FB is connected via fibre and has both IPv4 and IPv6.

IPv6 is XXXX:XXXX:AAAA:AAAA::1
Prefix is XXXX:XXXX:YYYY:fe00::/56

Z is connected to FB via ethernet (from FB lan to Z wan).
On wan:

IPv6 is XXXX:XXXX:YYYY:fe00:BBBB:BBBB:BBBB:a273/128
Prefix is XXXX:XXXX:YYYY:fefc::/62

On lan, there are two IPv6:

First IPv6 is fd00:db80::1/60
Second IPv6 is XXXX:XXXX:YYYY:fefc::1/62

DT has several IPv6 addresses.

XXXX:XXXX:YYYY:fefc::2
XXXX:XXXX:YYYY:fefc:CCCC:CCCC:CCCC:513e
fd00:db80::2
fd00:db80::CCCC:CCCC:CCCC:513e

My configs are shown below.

/etc/config/dhcp

config dhcp 'lan'
        option interface 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        option ra_management '1'
        option dynamicdhcp '1'
        option leasetime '12h'
        option start '100'
        option limit '150'
        list dns '10.10.10.1'
        list dns 'fd00:db80::1'
        list domain 'z'

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

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh'

config host
        option name 'dt'
        option dns '1'
        option ip '10.10.10.2'
        option leasetime 'infinite'
        option mac '?'

/etc/config/firewall

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 target 'ACCEPT'
        option src 'wan'
        option proto 'udp'
        option dest_port '547'
        option name 'Allow DHCPv6 (546-to-547)'
        option family 'ipv6'
        option src_port '546'

config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option name 'Allow DHCPv6 (547-to-546)'
        option family 'ipv6'
        option src_port '547'

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 defaults
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'ACCEPT'
        option syn_flood '1'

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 forward 'REJECT'
        option input 'REJECT'
        option network 'wan wan6 wwan'

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

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

/etc/config/network

config globals globals
        option ula_prefix fd00:db80::/48

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

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '10.10.10.1'
        option gateway '10.10.10.1'
        option broadcast '10.10.10.255'

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

config interface 'wan'
        option ipv6 1
        option ifname 'eth0.2'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth0.2'
        option proto 'dhcpv6'

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

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

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

config interface 'wwan'
        option proto 'dhcp'

Additionally, the following might be helpful.

ifstatus wan6

{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "uptime": 3197,
        "l3_device": "eth0.2",
        "proto": "dhcpv6",
        "device": "eth0.2",
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "XXXX:XXXX:YYYY:fe00:BBBB:BBBB:BBBB:a273",
                        "mask": 128,
                        "preferred": 2207,
                        "valid": 5807
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "XXXX:XXXX:YYYY:fefc::",
                        "mask": 62,
                        "preferred": 2207,
                        "valid": 5807,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": ""XXXX:XXXX:YYYY:fefc::",
                                        "mask": 62
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": ""XXXX:XXXX:YYYY:fe00::",
                        "mask": 64,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 6837,
                        "source": "::/0"
                },
                {
                        "target": ""XXXX:XXXX:YYYY:fe00::",
                        "mask": 56,
                        "nexthop": "fe80::DDDD:DDDD:DDDD:12ce",
                        "metric": 512,
                        "valid": 1437,
                        "source": ""XXXX:XXXX:YYYY:fefc::/62"
                },
                {
                        "target": ""XXXX:XXXX:YYYY:fe00::",
                        "mask": 56,
                        "nexthop": "fe80::DDDD:DDDD:DDDD:12ce",
                        "metric": 512,
                        "valid": 1437,
                        "source": ""XXXX:XXXX:YYYY:fe00:BBBB:BBBB:BBBB:a273/128"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::DDDD:DDDD:DDDD:12ce",
                        "metric": 512,
                        "valid": 1437,
                        "source": ""XXXX:XXXX:YYYY:fefc::/62"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::DDDD:DDDD:DDDD:12ce",
                        "metric": 512,
                        "valid": 1437,
                        "source": ""XXXX:XXXX:YYYY:fe00:BBBB:BBBB:BBBB:a273/128"
                }
        ],
        "dns-server": [
                "fd00::DDDD:DDDD:DDDD:12ce"
        ],
        "dns-search": [

        ],
        "neighbors": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ],
                "neighbors": [

                ]
        },
        "data": {
                "passthru": "????"
        }
}

If you need any more information, just ask!

trendy · March 28, 2020, 12:15pm

First of all remove this from LAN interface.

Also these are not needed in DHCP/lan, as OpenWrt will advertise itself as nameserver by default.

Other than that since the FritzBox is replying to your pings and is responding to the traceroute I don't see any other problem on OpenWrt, at least from what I can interpret from these masked IPs.
Maybe you can run a tcpdump and see whether the packets are leaving from the proper interface with the proper source address and if there is any icmp response for the reason it failed.

zacharyrs · March 28, 2020, 10:13pm

I've made the edits you mentioned - currently rebuilding.

Regarding tcpdump, I'm a bit of a newbie... I've included it in my build, so I assume I just run something like tcpdump -n -i eth0.2 on the router, then try my ping/traceroute?

Also, if it would help, I'm happy to DM you with the uncensored IPs?

trendy · March 28, 2020, 10:34pm

Better make the tcpdump more specific or it will collect a lot of useless packets.
For example: tcpdump -i eth0.2 -vn ip6 or tcpdump -i eth0.2 -vn icmp6 or tcpdump -i eth0.2 -vn host SOME_IPV6_ADDR or a combination of these.
You could alter some characters in the addresses, for example make 2001:1234 into 2016:abcd but to keep it consistent.

zacharyrs · March 28, 2020, 11:49pm

So I ended up running tcpdump -n -i eth0.2 -v -w eth.pcap & tcpdump -n -i br-lan -v -w br-lan.pcap & on Z, along with a series of pings/traceroutes.

In particular, I tested the following:

XXXX:XXXX:AAAA:AAAA::1 (FB)
XXXX:XXXX:YYYY:fefc::2 (DT)
XXXX:XXXX:YYYY:fefc:CCCC:CCCC:CCCC:513e (DT)
fd00:db80::2 (DT)
fd00:db80::CCCC:CCCC:CCCC:513e (DT)
fd00:db80::1 (Z)
2606:4700:4700::1111 (Cloudflare - external)

For each of these addresses, I ran ping and traceroute on the router, and then ping on my desktop (Windows).

I've filtered the packets down in Wireshark after - but honestly, I don't know what I'm looking for...

I'm happy to DM you the packet captures if you don't mind looking at it?

Also, regarding masking the IPs, I did just replace the recurring patterns - the X's used be something like 2606:1234, the Y's 5678, and the A's, B's, and C's were all other strings.

trendy · March 29, 2020, 1:13am

First you want to verify that a packet coming in from lan does indeed exit wan and is not dropped somewhere in the OpenWrt.
Second you want to verify that source and destination IPs are fine and there is no reason for Fritzbox to drop them.
If everything looks good, then you need to look at Fritzbox if it is forwarding the packets or not and why.

zacharyrs · March 29, 2020, 3:00am

So I'm just trying to follow the ICMPv6 stuff from when I pinged Cloudflare.

With br-lan open, I filtered for ipv6.dst_host == 2606:4700:4700::1111 - this should be the packets sent from my desktop? There's a number of results, and all show ASUSTekC on the source comment - that fits given my motherboard is from Asus.

What's odd is the source IPv6 is XXXX:XXXX:YYYY:fefc:EEEE:EEEE:EEEE:4c3b - which isn't an IP I've seen associated with anything yet. Actually just looking at ipconfig, it seems this is my desktop's temporary IP address?

Proceeding onto the capture from eth0.2, I again filtered with ipv6.dst_host == 2606:4700:4700::1111. I can see packets with the same source as above, so it looks like they made it through OpenWrt?

Note that in both the lan and eth captures, the info section says 'no response found!' - I assume this means I never got a reply back? That could be either the FB never sent it out, or the packets never made it back?

To clarify, I shouldn't have to open my router up to the internet right? The FB should see the destination and forward it through as needed? Or perhaps I'm completely wrong here...

trendy · March 29, 2020, 11:49am

This is the destination address, but it is better to just use host, in order to capture return traffic too. Or to use the source address as host to see if there are any icmp6 error messages.

It is possible if privacy extensions are in place.

Again better filter only host to be able to see return traffic.
In any case you should be able to see the same source and destination IPv6 addresses. MAC addresses will be different though, but this is how it works.

Yes, but I doubt the cloudflare server didn't respond. You can try other addresses too, but it seems to me that the problem lies on Fritzbox.

That is right. There is lan->wan forwarding on the OpenWrt, so nothing else is needed here.

zacharyrs · March 30, 2020, 9:44am

I did play around with the ipv6.host too, but there was the exact same data. I've just given it a go using the source as host, but there are no error messages - just the no response found.

I'm not exactly sure what privacy extensions are, but I suppose it must be enabled? A quick google suggests it's enabled on Windows by default.

Yeah the source was the same, but the mac showed the router - I think that's expected?

Yeah, the Cloudflare server usually responds. It's only going through my router that I have this issue - connecting directly to the FB via my phone (for example) has full IPv6 functionality.

Given I didn't see any responses on the router, I suppose there are a couple of possibilities...

FB never sent out the packet, hence there was no reply.
FB sent out the packet, but it never made it back. I figure this isn't really an option in this case.
FB sent out the packet but didn't send it back to Z, so Z couldn't forward it through to DT.

Of those, I suppose it has to be 1 or 3, but I'm not exactly sure how I can check...
I guess I could host a server on IPv6, try talking to it, and see if the server gets a hit?

Just wondering, if there's an issue with the firewall dropping packets, would they have shown in my capture? For example, say FB did get a reply and forward it through, it should definitely show in the capture right?

trendy · March 30, 2020, 10:29am

It doesn't hurt, unless you are running a server and you need a stable IP. But it can be troublesome when troubleshooting like you do. So you could switch it off till you figure it out.

Yes, the mac has validity on the link only.

If you see the packets going out of the OpenWrt the Fritzbox will get them. What does it do with them is something you'll have to troubleshoot with the vendor or your ISP.
Judging by other issues reported by users you are not the only one suffering from misbehaving isp routers and IPv6.

The capture is on the wire, before the firewall. So in case of incoming packet you'd see it on the capture and then the firewall would drop it. In case of outgoing packet the firewall would drop it before it would be captured and you wouldn't see anything.

zacharyrs · March 30, 2020, 11:59pm

Yeah my thought was host a server publicly, which has an IPv6 address. Then try communicate to that from my desktop.

I should see packets going through my router, and then if they go through FB they should hit my server - that way I can determine if FB is actually sending or dropping packets on the way out.

I suspect it's sending them fine, but isn't forwarding what it gets back to me... Unfortunately that makes things harder to debug.

Ah okay, thanks for clarifying that!

Turns out FB can actually do packet captures - http://fritz.box/html/capture.html.
I gave that a go, capturing on the ethX interfaces (eth0-eth3).

On eth1, I found the outgoing ping packets - with my desktop's temporary IPv6 as the source.
I tried looking at the other packets with that (using ipv6.addr == <tmp ipv6>), but there were only the four outgoing pings (destination being Google's IPv6).

Listening on eth0, which should be lan1 (where the fibre modem is plugged in), it seems there's actually no IPv6 traffic...

It gets better - it seems that all IPv6 is failing now. I suppose this just proves it's either the fritzbox, or just ISP? I'll leave it for now and see what happens...