PfSense does not get an IPv6 address on WAN

bimmerdriver

As I said above, a possible cause for dhcp6c not starting is because pfsense is waiting for the edge router to respond with RA. pfsense will wait forever for the RA and will not start dhcp6c. ipv6 will not work at all. If you're not sure whether your isp edge router requires a dhcp6 solicit before it will respond to an RS, download the 2.4 development snapshot and configure the wan with "do not wait for RA". If that doesn't solve your problem, maybe someone else has another idea.

Maps

Where did I found a nano version from 2.4 ? Or does the memstick version works too with the SD card in my Alex app ?

Maps

I saw NanoBSD is not supported on 2.4.
What did the RA don´t wait done ? Is it only web path and i am able to do it in a config file by hand or a dhcp6c path ?

Offtopic @ other "Deutsche Glasfaser" user. What is your plan to apply the Telefon functions ? sipproxy, asterisk on pfsense ?

bimmerdriver

@Maps:

What did the RA don´t wait done ? Is it only web path and i am able to do it in a config file by hand or a dhcp6c path ?

Normally when pfsense starts, it sends an RS, waiting for an RA, then when the RA is received, it starts dhcp6c. Some ISPs have configured their edge routers to not respond to an RS until after a dhcp solicit is received. In that case, there is a deadlock causing dhcp6c to never start. If you can get a prefix by manually starting dhcp6c, it's an indication that this may be happening. The feature is enabled using the webgui in the wan settings, but it's only available in 2.4. (There were some patches to 2.3, but not sure if they are compatible with 2.3.2_1.)

Just install the 2.3 development version, it's working fine. All the additions for Don't wait for RA have been included.

Maps

I can confirm, with don´t wait RA, in the 2.3 Dev Release I got the IPV6 network IP on WAN.

@Maps:

I can confirm, with don´t wait RA, in the 2.3 Dev Release I got the IPV6 network IP on WAN.

Good news.

I stopped updating the patches months ago when it was included in the 2.3 dev versions and I never got around to writing them for earlier releases.

Maps

I think there is a small issue in the fix.
When I had change the settings in the lan interface, the system will save and apply the setting,then the ipv6 will not come back.
When I release the Wan IP and renew it with the gui the IPV6 Net will come back.

It is possible , in this case the RA settings will not be used ?

@Maps:

I think there is a small issue in the fix.
When I had change the settings in the lan interface, the system will save and apply the setting,then the ipv6 will not come back.
When I release the Wan IP and renew it with the gui the IPV6 Net will come back.

It is possible , in this case the RA settings will not be used ?

No there is no issue with the fix. When you take down the LAN interface you clear it, the IPv6 address and PD is created by the script that runs when the WAN interface goes online. You just need to be aware of the way that prefix delegation works. If you left it long enough then I suspect that the dhcp6 time would expire and then refresh, giving you an address and prefix again; of course how long you would need to wait depends on your ISP and the lease renewal interval, mine is 30 minutes but others could be a day or two or even longer.

bimmerdriver

There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.

@bimmerdriver:

There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.

I've not been looking at this thread or the 5993 issue for months, I've been a bit busy with real work. :)

Couple of questions, does dhcp6c shutdown on WAN release and does dpinger shut down also?

I think I know why this isn't high on the list of things to fix, you are unlikely to run pfSense without the WAN interface online, it serves no purpose and I tend to make any changes required, which are few and rare and then reboot.

@bimmerdriver:

There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.

Can you send me a couple of images showing the interface and what you mean, you have my pm.

bimmerdriver

@marjohn56:

@bimmerdriver:

There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.

Can you send me a couple of images showing the interface and what you mean, you have my pm.

Email sent.

bimmerdriver

@marjohn56:

@bimmerdriver:

There is a small issue with the fix, but it's different from what was described. If you release the WAN interface then watch the "gateways status" on the dashboard, the WAN_DHCP status will go offline, but the WAN_DHCP6 status will stay online. If you leave it like this (i.e., if you don't renew the WAN interface), eventually, the WAN_DHCP6 status will go offline. This problem wasn't always there. It was introduced when another issue relating to the startup and shutdown of other dhcp processes was fixed. It's not a show stopper, but something seems to not be working properly. Refer to https://redmine.pfsense.org/issues/5993.

I've not been looking at this thread or the 5993 issue for months, I've been a bit busy with real work. :)

Couple of questions, does dhcp6c shutdown on WAN release and does dpinger shut down also?

I think I know why this isn't high on the list of things to fix, you are unlikely to run pfSense without the WAN interface online, it serves no purpose and I tend to make any changes required, which are few and rare and then reboot.

Here are the dhc* processes with everything running normally:

root    29136   0.0  0.1   8204  2188  -  Is   18:33     0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d localdomain -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts
dhcpd   42701   0.0  0.7  22808 13868  -  Ss   18:33     0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid hn0
dhcpd   44541   0.0  0.6  20760 11644  -  Ss   18:33     0:00.00 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn0
root    45032   0.0  0.1   6152  1920  -  Is   18:33     0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases
root    49261   0.0  0.1  10496  2384  -  Is   14:00     0:00.00 dhclient: hn1 [priv] (dhclient)
_dhcp   53588   0.0  0.1  10496  2488  -  Is   14:00     0:00.04 dhclient: hn1 (dhclient)
root    54290   0.0  0.1   8340  2216  -  Is   14:00     0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_hn1.pid hn1
root    90460   0.0  0.1  10448  2516  -  Ss   13:08     0:08.12 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf

Here are the dpinger processes:

root    33207   0.0  0.1  10952  2408  -  Is   14:01     0:02.91 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 50.98.86.223 -p /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.pid -u /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 50.98.84.1
root    33564   0.0  0.1  10952  2436  -  Is   14:01     0:03.38 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::215:5dff:fe5c:e21e%hn1 -p /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.pid -u /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::ea4:2ff:fe29:5001%hn1

Here are the dhc* processes with the interface released:

dhcpd   36277   0.7  0.6  20760 11644  -  Ss   18:37     0:00.00 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn0
root    36560   0.6  0.1   6152  1920  -  Ss   18:37     0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases
root    29136   0.0  0.1   8204  2188  -  Is   18:33     0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d localdomain -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts
dhcpd   42701   0.0  0.7  22808 13868  -  Ss   18:33     0:00.02 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid hn0
root    90460   0.0  0.1  10448  2516  -  Ss   13:08     0:08.13 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf

Here are the dpinger processes:

root    33207   0.0  0.1  15048  2492  -  Is   14:01     0:02.96 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 50.98.86.223 -p /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.pid -u /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 50.98.84.1
root    33564   0.0  0.1  10952  2436  -  Is   14:01     0:03.44 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::215:5dff:fe5c:e21e%hn1 -p /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.pid -u /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::ea4:2ff:fe29:5001%hn1

Here are the dhc* processes after renew:

dhcpd   46926   0.0  0.7  22808 13868  -  Ss   18:38     0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid hn0
root    72135   0.0  0.1  10496  2384  -  Is   18:38     0:00.00 dhclient: hn1 [priv] (dhclient)
_dhcp   76998   0.0  0.1  10496  2488  -  Ss   18:38     0:00.00 dhclient: hn1 (dhclient)
root    77847   0.0  0.1   8340  2216  -  Ss   18:38     0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_hn1.pid hn1
dhcpd   90268   0.0  0.6  20760 11644  -  Ss   18:39     0:00.00 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn0
root    90460   0.0  0.1  10448  2516  -  Ss   13:08     0:08.16 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf
root    90592   0.0  0.1   6152  1920  -  Ss   18:39     0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh -l /var/dhcpd/var/db/dhcpd6.leases
root    99184   0.0  0.1   8204  2188  -  Ss   18:38     0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d localdomain -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts

Here are the dpinger processes:

root    94836   0.0  0.1  10952  2408  -  Is   18:39     0:00.15 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 50.98.86.223 -p /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.pid -u /var/run/dpinger_WAN_DHCP~50.98.86.223~50.98.84.1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 50.98.84.1
root    94938   0.0  0.1  10952  2436  -  Is   18:39     0:00.02 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP6 -B fe80::215:5dff:fe5c:e21e%hn1 -p /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.pid -u /var/run/dpinger_WAN_DHCP6~fe80::215:5dff:fe5c:e21e%hn1~fe80::ea4:2ff:fe29:5001%hn1.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 fe80::ea4:2ff:fe29:5001%hn1

unbound and radvd do not automatically restart on their own after renewing the interface. They have to be manually restarted.

I have set the DHCP Reservation and Static DHCP options in the resolver settings.

Let me know if you need any more info.

I agree this isn't a show-stopper, but if the ISP service is interrupted, pfsense may not come back without manual intervention.

Just to confirm to others reading this thread, I checked this earlier and my pfSense behaves; however we are running different versions, I am running the latest 2.3 snapshot where BimmerDriver is running 2.4. I will run up a test version of 2.4 and try and confirm this issue and take if from there, providing real work does not get in the way again!

bimmerdriver

@marjohn56:

Just to confirm to others reading this thread, I checked this earlier and my pfSense behaves; however we are running different versions, I am running the latest 2.3 snapshot where BimmerDriver is running 2.4. I will run up a test version of 2.4 and try and confirm this issue and take if from there, providing real work does not get in the way again!

I just downloaded the latest 2.3 and 2.4 snapshots and I will perform a clean installation using both versions to see if there is any difference in the behaviour I described above.

bimmerdriver

@bimmerdriver:

@marjohn56:

Just to confirm to others reading this thread, I checked this earlier and my pfSense behaves; however we are running different versions, I am running the latest 2.3 snapshot where BimmerDriver is running 2.4. I will run up a test version of 2.4 and try and confirm this issue and take if from there, providing real work does not get in the way again!

I just downloaded the latest 2.3 and 2.4 snapshots and I will perform a clean installation using both versions to see if there is any difference in the behaviour I described above.

I just checked both 2.3 and 2.4 clean installations. Setup is identical. Virtually everything default except wait for RA and prefix only (/56). Also set unbound to register leases and static addresses. The dpinger issue is exactly the same. I did notice that the restart of radvd is not consistent. Sometimes it does restart on its own. I will post logs or whatever other info anyone would like to see.

It's certainly strange, I cannot make it do anything wrong in this respect.

What's your hardware and are you using a RAM for temp?

bimmerdriver

@marjohn56:

It's certainly strange, I cannot make it do anything wrong in this respect.

What's your hardware and are you using a RAM for temp?

Both systems are running on a hyper-v 2012 R2 server and I'm not using RAM for temp.

I'm not clear how dpinger works, but if it's pinging the ISP edge router, it would appear that releasing the interface doesn't seem to be actually releasing the ipv6 interface, at least not right away.

I think it's using the link local address for pinging ipv6, at least it is with my system; this may be part of the problem as that's not released. I have switched back to 2.4 now so I'll do some more testing this week and see what shows up.