Troubleshooting IPv6 Connectivity on OpenWrt: Fixing DHCPv6 Issues

As IPv6 adoption continues to grow, ensuring seamless connectivity across both IPv4 and IPv6 networks is becoming increasingly critical for businesses and home users alike. OpenWrt, a popular open-source router firmware, provides robust support for IPv6, but sometimes users encounter issues with obtaining an IPv6 address or prefix delegation from their Internet Service Provider (ISP). This post will walk you through a recent troubleshooting experience where we resolved a DHCPv6 issue on OpenWrt by adjusting firewall rules and performing other key diagnostic steps.

The Problem: WAN6 Interface Stuck in Pending State

While configuring an OpenWrt router to work with an ISP that supports IPv6 (in this case, Xfinity), we encountered an issue where the WAN6 interface remained in a pending state. Despite receiving a valid IPv6 address and prefix delegation from the ISP’s DHCPv6 server, the interface was not fully coming up. As a result, devices on the network were unable to obtain IPv6 connectivity.

Key Symptoms:

• The router was receiving an IPv6 address and a /60 prefix delegation from the ISP.
• The WAN6 interface remained in a “pending” state.
• Devices on the LAN were not able to access external IPv6 resources.
• Manually adding a default route allowed temporary IPv6 connectivity, but the underlying issue persisted.

Solution: Adjusting Firewall Rules for DHCPv6 Traffic

After investigating the issue, we discovered that the firewall rules were restricting DHCPv6 traffic to specific IP ranges (fc00::/6), which limited the ability of the router to properly communicate with the ISP’s DHCPv6 server. By broadening the firewall rule to allow DHCPv6 traffic from all sources, we were able to resolve the issue. Here’s the firewall rule that ultimately solved the problem:

config rule
    option name 'Allow-DHCPv6-All-Sources'  # New name for clarity
    option src 'wan'                         # From WAN zone
    option proto 'udp'                      # Use UDP protocol
    option dest_port '546'              # DHCPv6 port
    option family 'ipv6'                    # For IPv6 only
    option target 'ACCEPT'              # Allow the traffic

This rule ensures that any incoming DHCPv6 traffic on port 546 (the standard port for DHCPv6) is accepted, regardless of its source IP address. This change allowed the router to properly receive and process DHCPv6 messages from the ISP’s server.

Additional Troubleshooting Steps

In addition to adjusting the firewall rules, we performed several other diagnostic steps to ensure full IPv6 functionality. Here’s a breakdown of those steps:

1. Manually Adding a Default IPv6 Route

At one point during troubleshooting, we manually added a default route using the link-local address of our ISP’s gateway. This temporarily restored IPv6 connectivity:

ip -6 route add default via fe80::20b:12aa:fb00:99 dev eth1

While this provided temporary relief, it was clear that manually adding routes was not a sustainable solution. This led us to investigate deeper into firewall rules and DHCPv6 behavior.

2. Verifying WAN6 Configuration

We reviewed our WAN6 configuration in /etc/config/network to ensure proper settings for requesting an IPv6 address and prefix delegation:

config interface 'wan6'
    option proto 'dhcpv6'
    option reqaddress 'try'
    option reqprefix '60'  # Request /60 prefix as provided by Xfinity
    option device 'eth1'   # Ensure this matches your WAN interface

This configuration ensures that OpenWrt requests both an individual IPv6 address (IA_NA) and a prefix delegation (IA_PD) from the ISP.

3. Checking System Logs

We used system logs to identify any errors related to DHCPv6 or interface configuration. The following commands helped us gather relevant information:

logread | grep dhcp
logread | grep odhcpd
logread | grep wan6

By reviewing these logs, we confirmed that while DHCPv6 solicitations were being sent and responses were received, certain firewall restrictions were preventing full communication between the router and ISP’s server.

4. Ensuring Proper ICMPv6 Handling

ICMPv6 is essential for many aspects of IPv6 networking, including Router Advertisements (RA) and Neighbor Discovery Protocol (NDP). We verified that our firewall rules allowed ICMPv6 traffic by including rules such as:

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 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    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 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option family 'ipv6'
    option target 'ACCEPT'

These rules ensure that ICMPv6 messages are properly handled by both WAN and LAN interfaces.

Conclusion

By adjusting our firewall rules to allow unrestricted DHCPv6 traffic from all sources, we successfully resolved an issue where OpenWrt’s WAN interface was stuck in a pending state. In addition to this key adjustment, verifying proper ICMPv6 handling and reviewing system logs played critical roles in diagnosing and resolving this problem. If you’re experiencing similar issues with your OpenWrt setup, be sure to check your firewall rules and ensure they are not overly restrictive when it comes to handling essential protocols like DHCPv6 and ICMPv6. With these adjustments in place, you can ensure smooth operation of your network across both IPv4 and IPv6 environments. For more technical insights or assistance with network configurations, feel free to contact our team. We specialize in optimizing network performance for businesses of all sizes.