IPv6 difficulty



  • Hey All,

    I've had trouble with IPV6 for some time now. It seems to be that when the ipv6 address changes the network doesn't get updated.

    from pfSense's page:
    my WAN ipv6 address is:
    2600:8800:ff09:600:f483:5e9d:5a21:xxxx

    my LAN ipv6 address is:
    2600:8800:4300:16:8e:42ff:fec2:ea00

    I can reach and ping ipv6 hosts from pfsense, and pinging google works fine:
    PING6(56=40+8+8 bytes) 2600:8800:ff09:600:f483:5e9d:5a21:381f –> 2607:f8b0:4007:80c::200e
    16 bytes from 2607:f8b0:4007:80c::200e, icmp_seq=0 hlim=56 time=25.523 ms

    Unfortunately the same cannot be said for computers on my network:
    PC ipv6 address:
    2600:8800:4300:16::xxxx

    C:\Users\user>ping google.com

    Pinging google.com [2607:f8b0:4007:80c::200e] with 32 bytes of data:
    Request timed out.
    Request timed out.

    For comparison, ipv4:
    C:\Users\user>ping ipv4.google.com

    Pinging ipv4.l.google.com [172.217.6.78] with 32 bytes of data:
    Reply from 172.217.6.78: bytes=32 time=35ms TTL=55
    Reply from 172.217.6.78: bytes=32 time=34ms TTL=55

    if I release and renew my WAN interface this will work as normal for a time.

    Is there something that I need to change to fix this or is it a bug?
    Matt



  • Many people are using pfsense with ipv6, so it's more likely that there is a configuration problem on your system.

    It would help if you posted more background info, such as the following screen shots

    status interfaces, gateways
    interfaces wan, lan
    services dhcp6 / ra

    Also, what version of pfsense are you using and what is your isp?



  • Thank you for looking into it. The requested pages are here:
    https://appus.org/files/pfsense/

    With respect to the version:
    2.3.4-RELEASE (amd64)

    My ISP is Cox. One thing I do see that is probably not right is the prefix delegation being /48.



  • Unless  there is a good reason not to, I would suggest you switch to 2.4B. There have been a lot of changes on V6, some of those have not been backported to 2.3.*

    2.4B is VERY stable, at least on the systems I know that are running it.



  • @PertFlavus:

    Hey All,

    I've had trouble with IPV6 for some time now. It seems to be that when the ipv6 address changes the network doesn't get updated.

    The first thing you should do is find out why the address is changing.  It shouldn't.  PfSense uses something called a "DUID", which the ISP uses to identify it and then always assigns the same address block to it.  Previous versions of pfSense didn't handle this properly, so you might get different addresses.  However, the current version works fine, but you have to select "Do not allow PD/Address release" on the WAN tab.



  • @JKnott:

    @PertFlavus:

    Hey All,

    I've had trouble with IPV6 for some time now. It seems to be that when the ipv6 address changes the network doesn't get updated.

    The first thing you should do is find out why the address is changing.  It shouldn't.  PfSense uses something called a "DUID", which the ISP uses to identify it and then always assigns the same address block to it.  Previous versions of pfSense didn't handle this properly, so you might get different addresses.  However, the current version works fine, but you have to select "Do not allow PD/Address release" on the WAN tab.

    Hence the suggestion to change to 2.4B. There were also issues with dhcp6c, I modded that  for 2.4 - along with the DUID, but I never back-ported it.



  • I'm running 2.3.4 and it works fine with the DUID.



  • Good, then it may well be that the dhcp6c client is sending a release. Either that or the ISP is nuts.



  • @marjohn56:

    Good, then it may well be that the dhcp6c client is sending a release. Either that or the ISP is nuts.

    That's why I told him to check that "Do not allow PD/Address release" setting.  If it's not selected, the address will change, for something as minor as unplugging & reconnecting the Ethernet cable.

    In fact, I think that should be the default, rather than having to be selected.  I can't think of any reason why you'd want the addresses to change.



  • Thanks guys. I will give the option a try and see if I still have the same ipv6 in a week. I don't see a way to upgrade to 2.4B without doing a fresh install which I'd prefer to avoid so I'll wait until this comes out normally in the worst case.



  • @JKnott:

    @marjohn56:

    Good, then it may well be that the dhcp6c client is sending a release. Either that or the ISP is nuts.

    That's why I told him to check that "Do not allow PD/Address release" setting.  If it's not selected, the address will change, for something as minor as unplugging & reconnecting the Ethernet cable.

    In fact, I think that should be the default, rather than having to be selected.  I can't think of any reason why you'd want the addresses to change.

    Technically, it's a bit of a naughty. You are supposed to send a release when the client exits. It was a done as a dual pronged approach as some ISP's ignore the the fact that the DUID has not changed. ISP's  - domestic ones, are not obliged to provide the same address and/or PD range, and we found that we could only be certain 99.9% of the time that the allocation would remain if we did not send a release, as the BNG would then issue the existing lease if the DUID was the same. However, even if the DUID is the same and you don't send a release, if the lease time expires before the client re-connects the chances are you will get a different range/address.

    You might want to release on the odd occasion when you need to change your PD or IP, if some Muppet has gained access for some reason.



  • One thing that stands out to me, which may well be fixed in 2.4, is that even if the IP range changes for unexpected or undesired reasons, pfsense should be aware of that and update the dhcp6 range eventually. It's all well and good to prevent the IP from changing but it does seem like the root problem is still unaddressed. Is there perhaps a good reason why this shouldn't/can't be done?

    That said, I'm OK with being a bit naughty as a work around. At the end of the day I just want my stuff to work. I can always uncheck the box.



  • It should change and it does, at least it did, that was the reason we added the DUID hold option and the no-release option. There was also a bug that existed in the dhcp6c client itself which would still send a release even if told not to do so in certain circumstances, that one caused a some gnashing of teeth at one stage.



  • I mean the dhcp6server range to assign to my lan. the IP did change for pfsense itself, it just kept issuing the old range afterwards. Also the Lan ip didn't change. I might be misunderstanding you =)



  • No, the PD was changing also. Problem there was statically assigned addresses did not update but were then wrong, but dhcp6 assigned did, and that was the trigger for the work done on duid etc. For those of us running servers, any change was bad.



  • So I still ended up having problems with ipv6. Now what I've done is upgraded to 2.4.0 and unchecked the option to not allow PD/Address release. I have also enabled DHCP6 debug mode. I think these are the logs that would be of interest
    What I found this morning was that my interfaces only had ipv4 addresses. WAN had my ipv4 from my ISP and my lan interface had my local 10.0.0.1 ip only.

    After a release and renew I have both:
    WAN 1000baseT <full-duplex>24.56.52.77
    2600:8800:ff09:600:5961:7d35:c244:439
    LAN 10.0.0.1
    2600:8800:4300:5a:dc:6aff:fe48:4500

    It will be a day or three before the ipv6 falls off.

    As a side note, I'm really not sure why the date flipped from the 12th, to the 14th, and then back to the 12th.. but that is the order of system.log .. looks like less is showing it out of order or it's being duplicated in some way.

    Jul 12 06:19:11 pfSense php-fpm[89333]: /rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
    Jul 12 06:19:11 pfSense php-fpm[89333]: /rc.newwanipv6: Creating rrd update script
    Jul 12 06:19:11 pfSense php-fpm[89333]: /rc.newwanipv6: pfSense package system has detected an IP change or dynamic WAN reconnection - 2600:8800:ff09:600:9d4e:c38d:d082:4195 -> 2600:8800:ff09:600:5cf1:132b:272f:65bd - Restarting packages.
    Jul 14 05:33:04 pfSense php-fpm[26401]: /rc.newwanipv6: rc.newwanipv6: Info: starting on igb0.
    Jul 14 05:33:04 pfSense php-fpm[26401]: /rc.newwanipv6: rc.newwanipv6: on (IP address: 2600:8800:ff09:600:5961:7d35:c244:439) (interface: wan) (real interface: igb0).
    Jul 14 05:33:06 pfSense php-fpm[26401]: /rc.newwanipv6: ROUTING: setting default route to 24.56.52.1
    Jul 14 05:33:06 pfSense php-fpm[26401]: /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::215:f9ff:fe2a:7ed9%igb0
    Jul 14 05:33:06 pfSense php-fpm[26401]: /rc.newwanipv6: Removing static route for monitor fe80::215:f9ff:fe2a:7ed9 and adding a new route through fe80::215:f9ff:fe2a:7ed9%igb0
    Jul 14 05:33:06 pfSense php-fpm[26401]: /rc.newwanipv6: The command '/sbin/ifconfig igb0 inet6 2600:8800:ff09:600:5cf1:132b:272f:65bd delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'
    Jul 14 05:33:13 pfSense php-fpm[26401]: /rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
    Jul 14 05:33:13 pfSense php-fpm[26401]: /rc.newwanipv6: Creating rrd update script
    Jul 14 05:33:13 pfSense php-fpm[26401]: /rc.newwanipv6: pfSense package system has detected an IP change or dynamic WAN reconnection - 2600:8800:ff09:600:5cf1:132b:272f:65bd -> 2600:8800:ff09:600:5961:7d35:c244:439 - Restarting packages.
    Jul 12 06:16:25 pfSense php-fpm[2741]: /rc.newwanipv6: rc.newwanipv6: Info: starting on igb0.
    Jul 12 06:16:25 pfSense php-fpm[2741]: /rc.newwanipv6: rc.newwanipv6: on (IP address: 2600:8800:ff09:600:9d4e:c38d:d082:4195) (interface: wan) (real interface: igb0).
    Jul 12 06:16:27 pfSense php-fpm[2741]: /rc.newwanipv6: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1499865387] unbound[14934:0] error: bind: address already in use [1499865387] unbound[14934:0] fatal error: could not open ports'
    Jul 12 06:16:28 pfSense php-fpm[2741]: /rc.newwanipv6: ROUTING: setting default route to 24.56.52.1
    Jul 12 06:16:28 pfSense php-fpm[2741]: /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::215:f9ff:fe2a:7ed9%igb0
    Jul 12 06:16:28 pfSense php-fpm[2741]: /rc.newwanipv6: Removing static route for monitor fe80::215:f9ff:fe2a:7ed9 and adding a new route through fe80::215:f9ff:fe2a:7ed9%igb0
    Jul 12 06:16:28 pfSense php-fpm[2741]: /rc.newwanipv6: The command '/sbin/ifconfig igb0 inet6 2600:8800:ff09:600:81c6:473b:29ae:3cc delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'
    Jul 12 06:16:37 pfSense php-fpm[2741]: /rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
    Jul 12 06:16:37 pfSense php-fpm[2741]: /rc.newwanipv6: Creating rrd update script
    Jul 12 06:16:37 pfSense php-fpm[2741]: /rc.newwanipv6: pfSense package system has detected an IP change or dynamic WAN reconnection - 2600:8800:ff09:600:81c6:473b:29ae:3cc -> 2600:8800:ff09:600:9d4e:c38d:d082:4195 - Restarting packages.
    Jul 12 06:16:51 pfSense php-fpm[64742]: /rc.newwanipv6: rc.newwanipv6: Info: starting on igb0.
    Jul 12 06:16:51 pfSense php-fpm[64742]: /rc.newwanipv6: rc.newwanipv6: No IPv6 address found for interface WAN [wan].
    Jul 12 06:16:51 pfSense php-fpm[64742]: /rc.newwanipv6: rc.newwanipv6: Info: starting on igb0.
    Jul 12 06:16:51 pfSense php-fpm[64742]: /rc.newwanipv6: rc.newwanipv6: No IPv6 address found for interface WAN [wan].
    Jul 12 06:19:02 pfSense php-fpm[89333]: /rc.newwanipv6: rc.newwanipv6: Info: starting on igb0.
    Jul 12 06:19:02 pfSense php-fpm[89333]: /rc.newwanipv6: rc.newwanipv6: on (IP address: 2600:8800:ff09:600:5cf1:132b:272f:65bd) (interface: wan) (real interface: igb0).
    Jul 12 06:19:05 pfSense php-fpm[89333]: /rc.newwanipv6: ROUTING: setting default route to 24.56.52.1
    Jul 12 06:19:05 pfSense php-fpm[89333]: /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::215:f9ff:fe2a:7ed9%igb0
    Jul 12 06:19:05 pfSense php-fpm[89333]: /rc.newwanipv6: Removing static route for monitor fe80::215:f9ff:fe2a:7ed9 and adding a new route through fe80::215:f9ff:fe2a:7ed9%igb0
    Jul 12 06:19:05 pfSense php-fpm[89333]: /rc.newwanipv6: The command '/sbin/ifconfig igb0 inet6 2600:8800:ff09:600:9d4e:c38d:d082:4195 delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'

    I'm hoping you all might see a clue here to help me out or point me in the direction of a better log file. These look suspicious:
    Jul 14 05:33:06 pfSense php-fpm[26401]: /rc.newwanipv6: The command '/sbin/ifconfig igb0 inet6 2600:8800:ff09:600:5cf1:132b:272f:65bd delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'

    thank you in advance.

    Edit: I found the dhcp6c logs and have attached them, and my interface bridge config.
    between the 12th and this morning I have the following:
    Jul 12 06:23:21 pfSense dhcp6c[17300]: /var/etc/dhcp6c_wan.conf:13 invalid interface (bridge0): Device not configured
    Jul 12 06:23:21 pfSense dhcp6c[17300]: called
    Jul 12 06:23:21 pfSense dhcp6c[17300]: failed to parse configuration file
    Jul 14 05:26:11 pfSense dhcp6c[15931]: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:1e:bf:73:b6:00:08:a2:0a:77:e9
    Jul 14 05:26:11 pfSense dhcp6c[15931]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
    Jul 14 05:26:11 pfSense dhcp6c[15931]: failed initialize control message authentication

    this looks like the bug:
    https://redmine.pfsense.org/issues/6529
    or this one:
    https://redmine.pfsense.org/issues/3965

    Given that it hasn't gotten assigned a version since it was created a year ago.. looks like i'll need to get rid of the bridge.

    ![2017-07-14 10_22_06-pfSense.appus.org - Interfaces_ Bridges.png](/public/imported_attachments/1/2017-07-14 10_22_06-pfSense.appus.org - Interfaces_ Bridges.png)
    ![2017-07-14 10_22_06-pfSense.appus.org - Interfaces_ Bridges.png_thumb](/public/imported_attachments/1/2017-07-14 10_22_06-pfSense.appus.org - Interfaces_ Bridges.png_thumb)
    ![2017-07-14 10_21_48-pfSense.appus.org - Interfaces_ Interface Assignments.png](/public/imported_attachments/1/2017-07-14 10_21_48-pfSense.appus.org - Interfaces_ Interface Assignments.png)
    ![2017-07-14 10_21_48-pfSense.appus.org - Interfaces_ Interface Assignments.png_thumb](/public/imported_attachments/1/2017-07-14 10_21_48-pfSense.appus.org - Interfaces_ Interface Assignments.png_thumb)
    dhcp6c.txt</full-duplex>



  • It's not a dhcp6c problem per say, you are correct that the Bridge interface does not exist when dhcp6c fires up, so it's a start up issue.

    Until a full fix is found can I suggest a shell command is run at startup with a delay and then start dhcp6c from there. Not ideal I know, but it will get around the problem you have.