Project

General

Profile

Bug #11187

WAN_DHCP6 down, but IPv6 actually works

Added by Aleksandr Mezin 2 months ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Gateway Monitoring
Target version:
-
Start date:
12/22/2020
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.5.0
Affected Architecture:
All

Description

pfSense shows WAN_DHCP6 gateway as "Offline, Packetloss". However, IPv6 actually works: I can ping (successfully with 0 packet loss) ipv6.google.com from machines in the network and ping6 from the firewall itself, I can ping6 the gateway address from the firewall.

See the attached screenshots for configuration details.

It worked correctly on 2.4.5-p1 (gateway was 'Online') with the same configuration.

History

#1 Updated by Aleksandr Mezin 2 months ago

Doesn't happen anymore with Dec 23 build

#2 Updated by Aleksandr Mezin 2 months ago

And now the issue is back with Dec 26 build

Again, IPv6 is working fine, but gateway status shows "Offline, Packetloss"

#3 Updated by Aleksandr Mezin 2 months ago

Currently, WAN interface IPv6 address is fe80::201:c0ff:fe2a:b8d7%pppoe0, and gateway address is fe80::ea4:2ff:fe58:1001.

[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: ping6 fe80::ea4:2ff:fe58:1001
PING6(56=40+8+8 bytes) fe80::201:c0ff:fe28:1636%pppoe0 --> fe80::ea4:2ff:fe58:1001
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=0 hlim=255 time=0.683 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=1 hlim=255 time=0.616 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=2 hlim=255 time=0.611 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=3 hlim=255 time=0.572 ms
^C
--- fe80::ea4:2ff:fe58:1001 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.572/0.621/0.683/0.040 ms
[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: ping6 fe80::201:c0ff:fe2a:b8d7%pppoe0
PING6(56=40+8+8 bytes) fe80::201:c0ff:fe2a:b8d7%pppoe0 --> fe80::201:c0ff:fe2a:b8d7%pppoe0
16 bytes from fe80::201:c0ff:fe2a:b8d7%pppoe0, icmp_seq=0 hlim=64 time=0.245 ms
16 bytes from fe80::201:c0ff:fe2a:b8d7%pppoe0, icmp_seq=1 hlim=64 time=0.117 ms
16 bytes from fe80::201:c0ff:fe2a:b8d7%pppoe0, icmp_seq=2 hlim=64 time=0.129 ms
16 bytes from fe80::201:c0ff:fe2a:b8d7%pppoe0, icmp_seq=3 hlim=64 time=0.111 ms
16 bytes from fe80::201:c0ff:fe2a:b8d7%pppoe0, icmp_seq=4 hlim=64 time=0.189 ms
16 bytes from fe80::201:c0ff:fe2a:b8d7%pppoe0, icmp_seq=5 hlim=64 time=0.130 ms
^C
--- fe80::201:c0ff:fe2a:b8d7%pppoe0 ping6 statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.111/0.154/0.245/0.048 ms

Latest dpinger log entry:

send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr fe80::ea4:2ff:fe58:1001%pppoe0 bind_addr fe80::201:c0ff:fe2a:b8d7%pppoe0 identifier "WAN_DHCP6 " 

[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: ifconfig pppoe0
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
    inet 188.232.224.155 --> 172.20.44.254 netmask 0xffffffff
    inet6 fe80::201:c0ff:fe28:1636%pppoe0 prefixlen 64 scopeid 0x8
    inet6 fe80::201:c0ff:fe2a:b8d7%pppoe0 prefixlen 64 scopeid 0x8
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Interestingly, there are two link-local addresses:

[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: ping6 -S fe80::201:c0ff:fe28:1636%pppoe0 fe80::ea4:2ff:fe58:1001%pppoe0
PING6(56=40+8+8 bytes) fe80::201:c0ff:fe28:1636%pppoe0 --> fe80::ea4:2ff:fe58:1001%pppoe0
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=0 hlim=255 time=0.590 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=1 hlim=255 time=0.700 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=2 hlim=255 time=0.551 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=3 hlim=255 time=0.608 ms
16 bytes from fe80::ea4:2ff:fe58:1001%pppoe0, icmp_seq=4 hlim=255 time=0.576 ms
^C
--- fe80::ea4:2ff:fe58:1001%pppoe0 ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.551/0.605/0.700/0.051 ms

And the 2nd one seems to be incorrect?

[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: ping6 -S fe80::201:c0ff:fe2a:b8d7%pppoe0 fe80::ea4:2ff:fe58:1001%pppoe0
PING6(56=40+8+8 bytes) fe80::201:c0ff:fe2a:b8d7%pppoe0 --> fe80::ea4:2ff:fe58:1001%pppoe0
^C
--- fe80::ea4:2ff:fe58:1001%pppoe0 ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

But dpinger tries to use the 2nd one. Also, the 2nd one is displayed in the GUI.

#4 Updated by Aleksandr Mezin 2 months ago

And the 2nd address is in ppp logs...

[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: grep -i c0ff:fe2a:b8d7 /var/log/ppp.log
Dec 27 22:57:50 pfSense ppp[14781]: [wan]   0201:c0ff:fe2a:b8d7 -> 0ea4:02ff:fe58:1001
Dec 27 23:00:04 pfSense ppp[16456]: [wan]   0201:c0ff:fe2a:b8d7 -> 0ea4:02ff:fe58:1001
Dec 27 23:02:41 pfSense ppp[13547]: [wan]   0201:c0ff:fe2a:b8d7 -> 0ea4:02ff:fe58:1001
Dec 30 16:08:13 pfSense ppp[15873]: [wan]   0201:c0ff:fe2a:b8d7 -> 0ea4:02ff:fe58:1001

And the 1st one is not:

[2.5.0-DEVELOPMENT][root@pfSense.home.arpa]/root: grep -i c0ff:fe28:1636 /var/log/ppp.log

#5 Updated by Marcos Mendoza about 2 months ago

Having more than one link-local address on an interface can be normal. On the screenshot, you have the PD for the WAN interface as 64. This would generally be something like 48 or 56.

I don't see any commits between Dec 18 and Dec 28 which leads me to believe the snapshots were the same.
https://github.com/pfsense/pfsense/commits/master

#6 Updated by Aleksandr Mezin about 2 months ago

Yes, sometimes it just spontaneously starts working (showing the gateway is "online") after a few days (and sometimes it doesn't).

My ISP gives only /64 prefix.

#7 Updated by Aleksandr Mezin about 2 months ago

Also, sometimes the gateway shows as "online" after I changed some WAN settings -> "Save" -> "Apply changes". And rebooting (w/o changing anything) makes it "offline" again.

#8 Updated by Aleksandr Mezin 19 days ago

Still present on the current 2.5.0-RC

Simply rebooting also sometimes (in 50% cases maybe) fixes the issue.

Also sometimes when the IPv6 gateway is "down" after reboot I see a message about "loading rules failed" (will copy it here next time I see it)

#9 Updated by Aleksandr Mezin 13 days ago

Still present on 2.5.0

Aforementioned error message is unrelated, happens even when all gateways are "online", will open a separate bug report

#10 Updated by → luckman212 3 days ago

Does pfSense track the changes to dhcp6c that are being made by Marjohn56 on the opn side? Not sure if this is directly related, but there have been a couple of fixes there and it could be helpful to pull them in. May affect redmine #11454 too(?).

https://github.com/opnsense/dhcp6c/pull/27

https://github.com/opnsense/dhcp6c/commits/057afff600595a6e8c5b55710f12508492df6f54/dhcp6c.c

Not even sure which upstream pfSense is using. Is it:

https://github.com/hrs-allbsd/wide-dhcpv6/blob/freebsd/dhcp6c.c

or??

Also available in: Atom PDF