I vaguely remember requiring to allow something ICMP for IPv6 to work. Is that accurate? I can't find anything about it on IPv6 wiki pages...
You shouldn't be needing to add any additional rules, the default firewall rules are sufficient to allow ipv6 to work.
1 Like
I'm getting v6 addresses assigned to clients, but they're not getting v6 internet, and can't even ping the router. So I want to make sure I'm not missing anything on my end in terms of incorrect/incomplete configuration:
root@OpenWrt:~# uci export firewall
package firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
option flow_offloading '1'
option flow_offloading_hw '1'
option drop_invalid '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
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 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 zone
option name 'rent'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'RENT'
config zone
option name 'dmz'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'DMZ'
config forwarding
option src 'lan'
option dest 'dmz'
config forwarding
option src 'lan'
option dest 'rent'
config forwarding
option src 'dmz'
option dest 'wan'
config forwarding
option src 'rent'
option dest 'wan'
config rule
option name 'rent_Allow-DNS'
option src 'rent'
option src_port '53'
option target 'ACCEPT'
config rule
option name 'rent_Allow-DHCP'
list proto 'udp'
option src 'rent'
option src_port '67'
option target 'ACCEPT'
config rule
option name 'dmz_Allow-DNS'
option src 'dmz'
option src_port '53'
option target 'ACCEPT'
config rule
option name 'dmz_Allow-DHCP'
list proto 'udp'
option src 'dmz'
option src_port '67'
option target 'ACCEPT'
Is the problem with the lan interface or with RENT or DMZ?
If you have multiple LANs you need to be sure that prefixes were delegated to them properly.
1 Like
LAN; I'm getting assigned /64 by the ISP anyhow, so I can only have functional IPv6 in one of my networks. To be honest, I had v6 working on my previous OWrt router perfectly fine, and it's only after new router I'm having this issue. There is a reported bug on this, I'm only making this thread to make sure I didn't miss anything and that it is indeed the bug that's to blame.
Made a full reset of the router, set up all the settings, VLANs, interfaces, firewalls, Wi-Fi all over again. And still no sign of IPv6.
Extremely frustrated.
Does IPv6 work if you leave most everything at defaults so there is only one LAN running with default firewall settings?
Do they get GUA addresses (which start with 2 or 3) or just ULAs that start with FD? I would take out ula_prefix as most use cases do not require ULAs, most clients won't use a ULA to reach the Internet, and they are just confusing.
Didn't get to check as I've other users on the net that needs connection. But for that matter, I only add forwarding and allowing DNS and DHCP to the default firewall rules, so theoretically presence of other subnets shouldn't affect my LAN... Theoretically, anyhow. I can attempt again 24 hours later, when everybody's hopefully asleep.
Both, as I've left those with defaults. And the thing is, I can ping neither GUA nor the ULA of router's WAN interface. Best I can do is GUA of OpenWrt LAN interface, but ULA fails.
Removing ula_prefix was actually a suggested workaround on the bug report, and I tried it to no avail few weeks ago. But I don't remember how I tested it, maybe I went about the wrong way? After removing prefix on OWrt, do I restart both it and the network interface on client machine or is that unnecessary?
Just now confirmed at least two of the six total devices currently on my network can do IPv6 without any issue. Of the remaining six, one is yet unconfirmed, and all three of my personal devices cannot go beyond pinging the GUA on router's LAN interface.
With this context, is there anything I can do to debug the issue. Or do I just give up on trying by my lonesome and hope the GitHub report will gather enough attention and momentum to figure it out collectively.
Continuing the discussion from IPv6 on Android not working:
Welp. I don't know why, but this worked. While randomly browsing for IPv6 problems to learn if it'll help my situation, I came across this instruction, applied them and all devices have working IPv6 now.
More than a decade since I learned what little IPv6 that I've already forgotten long ago. I really don't know how to dissect why the original relay settings didn't working and this SLAAC thing did.
1 Like
That's interesting, I'm the author of that page, however it was just meant for creating proper SLAAC instead of default DHCPv6, never notice that ICMPv6 didn't work before (since I have tons of Android devices and my daily driver are Chromebook which strictly requiring SLAAC)
1 Like
Oh, I'm not sure ICMPv6 was even a problem on my network, this topic was to make sure all the v6 configuration was in order. I linked a bug report few replies ago, v6 relay configuration that used to work with my previous router no longer working on the new RT3200; apparently besides me there are other people facing the same problem and not just with RT3200. I've posted your SLAAC guide there, so it'll be interesting to see the outcome.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.