Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    IPv6 Address

    Scheduled Pinned Locked Moved IPv6
    ipv6att
    4 Posts 2 Posters 212 Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J Offline
      jdhutchin
      last edited by

      I'm losing the IPv6 address on my WAN interface after about an hour. If I reboot the router then it works again, for about an hour.

      I have ATT fiber and am using a WAS-110 PON stick to bypass the gateway. IPv4 connectivity works perfectly. Because I'm using the bypass I don't use the workarounds in https://github.com/lilchancep/att-pfsense-ipv6

      My IPv6 WAN settings- I request a /60 and have "Send IPv6 prefix hint" enabled and all other options left blank. I have also tried setting the "Do not allow PD/address release" option with no effect.

      In the dhcpd logs, I see it initially receives a response to a solicit but later I see it sending solicits and a renew with no response, and eventually the address times out and is removed. I've attached dhcp6c logs- sometimes it works due to a reboot or network interface reset (although that doesn't always work), I've also tried looking at packet captures and can't see any difference between the requests that get a response and ones that don't.

      I'm not sure what's going on here- is it an ATT issue, pfsense issue, or am I just missing some option? I also don't have an explanation for why it works on reboot but not after.

      dhcp6c_redacted.txt

      d20c3e9f-80d6-476f-9da5-8a5f484b15e5-image.png

      AndyRHA 1 Reply Last reply Reply Quote 0
      • AndyRHA Offline
        AndyRH
        last edited by

        I am away from mine, but I am not seeing the problem you describe. Tonight I will make some screenshots.

        o|||||||o
        8200

        1 Reply Last reply Reply Quote 0
        • AndyRHA Offline
          AndyRH @jdhutchin
          last edited by

          @jdhutchin I see some differences.

          f9e6c84f-dd24-48cc-9706-5cc01bab3eab-image.png

          o|||||||o
          8200

          1 Reply Last reply Reply Quote 0
          • J Offline
            jdhutchin
            last edited by

            I found my problem- I had an outbound NAT rule that applied to both IPv6 and IPv6 that was rewriting the source of UDP packets to the WAN address (not the link local address)
            efc1ad6d-3b8d-4b6b-8976-b92b583dbd9c-image.png

            When the ISP saw the packets from the GUA they were ignored- these are supposed to come from link-local. I guess the initial request went through because there was no WAN address for them to be rewritten to.

            Updating this rule to only affect ipv4 seems to have fixed my issue- I will have to wait a few hours to tell for sure but I see replies in packet captures.

            • WAN firewall allows ipv4+ipv6 UDP port 546, 547
            • MAC address on WAN is set to the address on the ATT gateway
            • "Do not allow PD/Address release" is unchecked.
            • "Prefer IPv4 over IPv6" is checked

            I found this by comparing packets from my primary ISP and my backup ISP-

            primary:

            5	28.595589	2001:XYZ::1	ff02::1:2	DHCPv6	156	Renew XID: 0x1ff509 CID: 0001000131609bcc0cc47a6cef34 IAA: 2001:XYZ:::::1 
            

            I eventually did a packet capture on my failover wan and saw these renew packets that did get a response:

            1	0.000000	fe80::ec4:7aff:fe6c:ef36	ff02::1:2	DHCPv6	130	Solicit XID: 0xd90503 CID: 0001000131609bcc0cc47a6cef34 
            

            Note these are coming from the link-local address instead of the GUA (2001::.XYZ)- this was the clue I needed to figure out the problem.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.