Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPV6 not obtaining changed/new Prefix (via DHCPv6)

    Scheduled Pinned Locked Moved
    2.4 Development Snapshots
    3
    6
    1.2k
    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.
    • D
      DerSchreiber
      last edited by

      I´m running a pfSense-Box as Multi-WAN Box with one ISP delivering IPv6 (/56 Prefix).

      Everything is runing (mostly) fine with getting an IPv6-Adress (via PD) on the WAN side (requesting /60 Prefix) and a /64 Adress on the LAN-Side and for all Clients (about 15-20) in the LAN behind the Box.

      Problem starts when the Prefix, delivered by the ISP-Router, changes (due to nightly reconnect or else). The pfSense completly notices the changes of the Interface (both IPv4 and IPv6) with Gateway-Alarm, lots of "check-reload-status", openvpn and dyndns updates. Until clearing the IPv4 gateway-alarm and (again) reloading filters, restarting tunnels and such.
      But: the IPv6 interface doesn´t pick the new Prefix and so IPv6 stays down.
      As soon as I am restarting the WAN-Interface manually, everything goes back to normal operation.

      Following settings are active:

      • Allow IPV6 (in Advanced/Networking)
      • WAN Interface: IPv6 Configuration Type: DHCP6, Ticked Request only an IPv6 Prefix, Send IPv6 prefix hint and Do not wait for RA. Prefix Delegation Size is set to 60.
      • LAN Interface: IPv6 Configuration Type: Track Interface.

      Once again: The problem is not the function itself but not picking up the changed IPv6 Prefix…

      Any advice?

      Regards
      Karsten

      PS: 2.4.2-DEVELOPMENT (amd64) built on Fri Nov 03 22:55:21 CDT 2017

      1 Reply Last reply Reply Quote 0
      • B
        bimmerdriver
        last edited by

        If your isp is giving a /56, why are you requesting a /60? If they reply with a /56, then you should request a /56. Try also setting do not allow release in the wan setting. If they really are changing the prefix every night, they are incompetent and you should complain. If they won't fix this, you should try another ISP. If you have no choice, you would be better off using hurricane electric for ipv6.

        1 Reply Last reply Reply Quote 0
        • D
          DerSchreiber
          last edited by

          I´m requesting a /60 ´cause the /56 is the net of the ISP´s Modem/Router, the /60 is the transit (LAN-Side of Modem/Router) and therefore (in my opinion) the best choice for Wan-Side of pfSense.

          I think, the ISP is not that incompetent - I wouldn´t like to use a static IPv6 adress… The changing prefix is a bit of privacy...

          Even if I´m going to repeat myself: Everything is fine - except pfSense is (as far as I can see) not aware of the change of the prefix...

          Considering the logs it kind of forgets to fire php-fpm 28910 /rc.newwanipv6 when checking reload status (as it does when stoping/starting the interface manually).

          13:03:42 - 13:04:11: ISP Modem/Routers obtaining new prefix.
          13:38:19 - 13:39:02: Restarting WAN-Interface

          Nov 4 13:39:02 php-fpm 48375 /rc.start_packages: Restarting/Starting all packages.
          Nov 4 13:39:01 check_reload_status Starting packages
          Nov 4 13:39:01 php-fpm 48375 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 192.168.238.1 - Restarting packages.
          Nov 4 13:39:01 check_reload_status Reloading filter
          Nov 4 13:39:01 php-fpm 48375 /rc.newwanip: rc.newwanip called with empty interface.
          Nov 4 13:39:01 php-fpm 48375 /rc.newwanip: rc.newwanip: on (IP address: 192.168.238.1) (interface: []) (real interface: ovpns1).
          Nov 4 13:39:01 php-fpm 48375 /rc.newwanip: rc.newwanip: Info: starting on ovpns1.
          Nov 4 13:39:01 php-fpm 48375 /rc.start_packages: Restarting/Starting all packages.
          Nov 4 13:38:59 check_reload_status rc.newwanip starting ovpns1
          Nov 4 13:38:59 check_reload_status Starting packages
          Nov 4 13:38:59 php-fpm 28910 /rc.newwanipv6: pfSense package system has detected an IP change or dynamic WAN reconnection - 2001:16b8:xxxx:6400:215:fdff:fef5:4733 -> 2001:16b8:xxxx:d800:215:fdff:fef5:4733 - Restarting packages.
          Nov 4 13:38:59 check_reload_status Reloading filter
          Nov 4 13:38:59 php-fpm 28910 /rc.newwanipv6: Creating rrd update script
          Nov 4 13:38:59 kernel ovpns1: link state changed to UP
          Nov 4 13:38:59 php-fpm 28910 OpenVPN PID written: 43689
          Nov 4 13:38:59 check_reload_status Reloading filter
          Nov 4 13:38:59 kernel ovpns1: link state changed to DOWN
          Nov 4 13:38:59 php-fpm 28910 OpenVPN terminate old pid: 88220
          Nov 4 13:38:59 php-fpm 28910 /rc.newwanipv6: Resyncing OpenVPN instances for interface WAN_1U1.
          Nov 4 13:38:58 php-fpm 28910 /rc.newwanipv6: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
          Nov 4 13:38:44 php-fpm 8701 /rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
          Nov 4 13:38:30 php-fpm 1248 /interfaces.php: Creating rrd update script
          Nov 4 13:38:30 check_reload_status Reloading filter
          Nov 4 13:38:30 php-fpm 1248 /interfaces.php: Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.1.1
          Nov 4 13:38:30 php-fpm 1248 /interfaces.php: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.3.1
          Nov 4 13:38:30 php-fpm 1248 /interfaces.php: Removing static route for monitor 2001:4860:4860::8844 and adding a new route through fe80::3631:c4ff:feb4:ebdf%hn1
          Nov 4 13:38:29 php-fpm 28910 /rc.newwanipv6: The command '/sbin/ifconfig hn1 inet6 2001:16b8:60d6:6400:215:fdff:fef5:4733 delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'
          Nov 4 13:38:29 check_reload_status Reloading filter
          Nov 4 13:38:29 php-fpm 28910 /rc.newwanipv6: Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.1.1
          Nov 4 13:38:29 php-fpm 28910 /rc.newwanipv6: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.3.1
          Nov 4 13:38:29 php-fpm 28910 /rc.newwanipv6: Removing static route for monitor 2001:4860:4860::8844 and adding a new route through fe80::3631:c4ff:feb4:ebdf%hn1
          Nov 4 13:38:29 php-fpm 28910 /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::3631:c4ff:feb4:ebdf%hn1
          Nov 4 13:38:29 php-fpm 28910 /rc.newwanipv6: ROUTING: setting default route to 192.168.3.1
          Nov 4 13:38:28 check_reload_status updating dyndns wan
          Nov 4 13:38:26 php-fpm 28910 /rc.newwanipv6: rc.newwanipv6: on (IP address: 2001:16b8:xxxx:d800:215:fdff:fef5:4733) (interface: wan) (real interface: hn1).
          Nov 4 13:38:26 php-fpm 28910 /rc.newwanipv6: rc.newwanipv6: Info: starting on hn1.
          Nov 4 13:38:24 rtsold Starting dhcp6 client for interface wan(hn1)
          Nov 4 13:38:24 rtsold Received RA specifying route fe80::3631:c4ff:feb4:ebdf for interface wan(hn1)
          Nov 4 13:38:23 check_reload_status Restarting ipsec tunnels
          Nov 4 13:38:23 php-fpm 1248 /interfaces.php: ROUTING: setting default route to 192.168.3.1
          Nov 4 13:38:21 php-fpm 1248 /interfaces.php: Starting rtsold process
          Nov 4 13:38:21 php-fpm 1248 /interfaces.php: Accept router advertisements on interface hn1
          Nov 4 13:38:21 php-fpm 1248 /interfaces.php: calling interface_dhcpv6_configure.
          Nov 4 13:38:21 kernel arpresolve: can't allocate llinfo for 192.168.3.1 on hn1
          Nov 4 13:38:21 php-fpm 1248 /interfaces.php: Shutting down Router Advertisment daemon cleanly
          Nov 4 13:38:20 kernel arpresolve: can't allocate llinfo for 192.168.3.1 on hn1
          Nov 4 13:38:19 check_reload_status Syncing firewall

          Nov 4 13:04:11 php-fpm 41262 /rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
          Nov 4 13:04:10 php-fpm 41262 /rc.dyndns.update: MONITOR: WANGW_1u1 is available now, adding to routing group Balancer 8.8.8.8|192.168.3.3|WANGW_1u1|16.954ms|0.279ms|0.0%|none
          Nov 4 13:04:10 php-fpm 64356 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW_1u1.
          Nov 4 13:04:09 check_reload_status Reloading filter
          Nov 4 13:04:09 check_reload_status Restarting OpenVPN tunnels/interfaces
          Nov 4 13:04:09 check_reload_status Restarting ipsec tunnels
          Nov 4 13:04:09 check_reload_status updating dyndns WANGW_1u1
          Nov 4 13:04:09 rc.gateway_alarm 65044 >>> Gateway alarm: WANGW_1u1 (Addr:8.8.8.8 Alarm:0 RTT:16963ms RTTsd:238ms Loss:0%)
          Nov 4 13:03:44 php-fpm 39271 /rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
          Nov 4 13:03:44 php-fpm 41262 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW_1u1.
          Nov 4 13:03:43 php-fpm 96077 /rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
          Nov 4 13:03:43 php-fpm 39271 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_1U1_DHCP6.
          Nov 4 13:03:43 php-fpm 96077 /rc.dyndns.update: MONITOR: WANGW_1u1 is down, omitting from routing group Balancer 8.8.8.8|192.168.3.3|WANGW_1u1|16.931ms|0.26ms|28%|down
          Nov 4 13:03:42 check_reload_status Reloading filter
          Nov 4 13:03:42 check_reload_status Restarting OpenVPN tunnels/interfaces
          Nov 4 13:03:42 check_reload_status Restarting ipsec tunnels
          Nov 4 13:03:42 check_reload_status updating dyndns WANGW_1u1
          Nov 4 13:03:42 rc.gateway_alarm 22406 >>> Gateway alarm: WANGW_1u1 (Addr:8.8.8.8 Alarm:1 RTT:16921ms RTTsd:250ms Loss:25%)
          Nov 4 13:03:42 check_reload_status Reloading filter
          Nov 4 13:03:42 check_reload_status Restarting OpenVPN tunnels/interfaces
          Nov 4 13:03:42 check_reload_status Restarting ipsec tunnels
          Nov 4 13:03:42 check_reload_status updating dyndns WAN_1U1_DHCP6
          Nov 4 13:03:42 rc.gateway_alarm 21901 >>> Gateway alarm: WAN_1U1_DHCP6 (Addr:2001:4860:xxxx::8844 Alarm:1 RTT:5927ms RTTsd:175ms Loss:23%)

          1 Reply Last reply Reply Quote 0
          • D
            DerSchreiber
            last edited by

            Supplemental Info:

            After the nightly reconect (03:59:20) the box startet (with no obvious trigger/reason) the /rc.newwanipv6 on 5:38:29. After that (see logs below) IPv6 was up again.
            Only dpinger threw an error, was not working (05:38:32) and needed a manually restart (09:10:24) (the IPv6-Address in the Log was the old, outdated one).

            As far as I can remember from prvious attempts, the rc.newwanipv6 usually comes up about 90 Minutes after the new Prefix was obatained by ISP-Router - not regarding the absolute time of day.

            Logs:

            Nov 5 09:10:24 php-fpm 64252 /status_services.php: Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.1.1
            Nov 5 09:10:24 php-fpm 64252 /status_services.php: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.3.1
            Nov 5 09:10:24 php-fpm 64252 /status_services.php: Removing static route for monitor 2001:4860:4860::8844 and adding a new route through fe80::3631:c4ff:feb4:ebdf%hn1
            Nov 5 09:06:41 pkg-static pfSense-repo upgraded: 2.4.2.a.20171103.1355 -> 2.4.2.a.20171104.1523

            Nov 5 05:38:32 check_reload_status Reloading filter
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: Error starting gateway monitor for WAN_1U1_DHCP6
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: The command '/usr/local/bin/dpinger -S -r 0 -i WAN_1U1_DHCP6 -B 2001:16b8:xxxx:d800:215:fdff:fef5:4733 -p /var/run/dpinger_WAN_1U1_DHCP6~2001:16b8:xxxx:d800:215:fdff:fef5:4733~2001:4860:4860::8844.pid -u /var/run/dpinger_WAN_1U1_DHCP6~2001:16b8:xxxx:d800:215:fdff:fef5:4733~2001:4860:4860::8844.sock -C "/etc/rc.gateway_alarm" -d 0 -s 500 -l 500 -t 20000 -A 1000 -D 500 -L 20 2001:4860:4860::8844 >/dev/null' returned exit code '1', the output was ''
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.1.1
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.3.1
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: Removing static route for monitor 2001:4860:4860::8844 and adding a new route through fe80::3631:c4ff:feb4:ebdf%hn1
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::3631:c4ff:feb4:ebdf%hn1
            Nov 5 05:38:32 php-fpm 38145 /rc.newwanipv6: ROUTING: setting default route to 192.168.3.1
            Nov 5 05:38:29 php-fpm 38145 /rc.newwanipv6: rc.newwanipv6: on (IP address: 2001:16b8:xxxx:d800:215:fdff:fef5:4733) (interface: wan) (real interface: hn1).
            Nov 5 05:38:29 php-fpm 38145 /rc.newwanipv6: rc.newwanipv6: Info: starting on hn1.
            Nov 5 05:00:13 php-cgi rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              @DerSchreiber:

              I think, the ISP is not that incompetent - I wouldn´t like to use a static IPv6 adress… The changing prefix is a bit of privacy...

              Really - privacy extensions provide the PRIVACY - the prefix not being fixed causes all sorts of challenges with firewall rules if you want incoming connections

              https://tools.ietf.org/html/rfc4941.html

              1 Reply Last reply Reply Quote 0
              • B
                bimmerdriver
                last edited by

                I wasn't clear that you were connecting pfsense to the ISP modem and getting a prefix from it. Does the modem allow a port to be bridged so you can get dedicated prefix for pfsense? That's what many people here are doing. I have two pfsenses connected this way, each with a separate prefix. The ISP SHOULD NOT be changing the prefix unless the DUID of the router changes or the router releases it. If they are routinely changing the prefix even if the DUID is unchanged and the router is not releasing it, they are not competent.

                As for changing prefix being a benefit for privacy, that's what a firewall is for. If you think changing prefix is a feature, you are probably one of the only pfsense users who thinks so. I agree with the other comment that "privacy" addresses are for privacy.

                pfsense does not deal with prefix changes very well. It could and should do a better job, but for some reason, it's not a priority. The feature "do not release prefix" was intended to prevent a prefix from changing due to pfsense releasing it.

                You should try connecting pfsense to a bridged port and see if the behaviour is different and you should ask the ISP why they are changing the prefix. If you are stuck with a frequently changing prefix, then you are going be dealing with firewall issues. I think you would be better off using a tunnel from hurricane electric than what your ISP is providing.

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