PfSense Release 2.1 Broken IPv6 PPPoE/SLAAC
-
I am an ALIX user with Teksavvy as an ISP. The provider assigns a /56 network routed via a /64.
For months I've been using an RC0 (June 24th) image without issue. After updating to 2.1-release I noticed IPv6 was no longer working. I've reverted to the RC0 for the time being and am hoping that some of the data I can collect from either instance will help to log a bug to get resolved. I'm just not quite sure what the bug is yet, so I'm hoping the community can help there.
Here's the interface status page on the working RC0 slice:
WAN interface (pppoe0) Status up PPPoE up Uptime 00:01:02 MAC address 00:00:00:00:00:00 IPv4 address 69.165.170.146 Subnet mask IPv4 255.255.255.255 Gateway IPv4 206.248.154.103 IPv6 Link Local fe80::5017:7332:bc7a:1f01 IPv6 address 2607:f2c0:a000:c:20d:b9ff:fe23:f3e0 Subnet mask IPv6 64 Gateway IPv6 fe80::90:1a00:4243:14a8
And here's the same info from the broken 2.1-release slice
WAN interface (pppoe0) Status up PPPoE up Uptime 00:03:08 MAC address 00:00:00:00:00:00 IPv4 address 69.165.170.146 Subnet mask IPv4 255.255.255.255 Gateway IPv4 206.248.154.103 IPv6 Link Local fe80::20d:b9ff:fe23:f3e1%vr1 Gateway IPv6 fe80::90:1a00:4243:14a8
The first thing I noticed is that the link local address is using the mac of the NIC itself. For awhile it was actually using the MAC of the LAN interface to generate it's IPv6 address. After messing around with it quite a bit, the install is now choosing the WAN interface mac when it creates the link local address.
I was able to find a guide to static IPv6 for teksavvy, by setting ip6 to static using 2607:f2c0:a000:c::1 for the address and gateway things started working. But when I switch back to SLAAC on WAN they die. I don't want to use 2.1-release with this hack because the gateway monitoring shows as down even through the FW is routing IPv6 traffic.
I did notice that on the release image the pppoe0 interface has a link local IPv6 address that's based on the LAN interface. RC0 has this, but it also has a link local that seems entirely made up, this is the link local address that is shown in the web UI snippet above. RC0 can ping the link local gateway address, but 2.1-Release cannot.
This almost seems like a routing issue. If anyone can help suggest ways to narrow this down or find any changes that may have caused this glitch I'd be grateful. I'm willing to reboot my firewall a few times in the name of making this a better product!
-
I'm not any help I'm afraid, but I've found the same thing - no working WAN-side IPv6 (also over PPPoE) after upgrading from RC0 to Release. Also on an Alix board, though I can't think that would be relevant.
I spent an hour or two trying stuff then gave up and went back to RC0. Not sure what to do now, especially as I didn't see anything in this forum which made me think it was more widespread.
-
I also have the same, a /48 and several /64 via PPPoE, simply doesn't work, but RC0 (edit: - memory failing me) does. This was on x86 on various Intel ITX boards, which rules out the Alix causing the problem.
I spent a few days on it but had to give up to get a working setup, now I'm under pressure not to touch it again :(Anyone else?
-
I have found that you can manually get this working by modifying the routing table.
It appears the pppoe link local address is calculated using the LAN interface mac, not sure if this contributes to the issues at all.
The IPv6 default gateway is wrongly assigned to the WAN hardware interface instead of the pppoe instance. In my setup the gateway was set to IP6_ADDR%vr1, and that needed a change to IP6_ADDR%pppoe0. Once the change was made IP6 is working, However, RRD graphs do not show the expected information regarding IP6
I issued this command from CLI to get things working: route change -inet6 default IP6_ADDR%pppoe0
I've submitted a bug for this issue here: https://redmine.pfsense.org/issues/3357
-
I confirm this bites me too.
pfsense 2.1-stable running on an alix, and it does the same on a 64 bit atom host and a 64 bit KVM guest.So my VDSL is delivered tagged as vlan 10, and I have to run PPPoE on the interface re0_vlan10.
Then I get a pppoe0 interface which has my real-world IPv4 and v6 addresses.V4 works fine all the time, but on connect this is the default route for v6
Internet6:
Destination Gateway Flags Netif Expire
default fe80::c664:13ff:fe9e:bf80%re0_vlan10 UGS re0_vlan10To fix it I have do do
route change -inet6 default fe80::c664:13ff:fe9e:bf80%pppoe0Giving a routing table entry of
Internet6:
Destination Gateway Flags Netif Expire
default fe80::c664:13ff:fe9e:bf80%pppoe0 UGS pppoe0then outbound IPv6 works.
There's a followon problem where INBOUND IPv6 connections don't work, and when I generate some inbound IPv6 traffic by ping6 or browsing http://criggie.org.nz/ then I see this
[2.1-RELEASE][root@pfsense.criggie.org.nz]/root( 8 ): tcpdump -i re0_vlan10 -nn ip6 or icmp6
tcpdump: WARNING: re0_vlan10: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0_vlan10, link-type EN10MB (Ethernet), capture size 96 bytes
18:16:28.882578 IP6 fe80::230:1bff:fe82:bcac > ff02::1:ff9e:bf80: ICMP6, neighbor solicitation, who has fe80::c664:13ff:fe9e:bf80, length 32
18:16:29.882107 IP6 fe80::230:1bff:fe82:bcac > ff02::1:ff9e:bf80: ICMP6, neighbor solicitation, who has fe80::c664:13ff:fe9e:bf80, length 32
…But its outside the pppoe session, and doesn't get anywhere.
Is this a related problem or something unique to having PADI and PADO packets on a vlan ?
-
….
This almost seems like a routing issue. If anyone can help suggest ways to narrow this down or find any changes that may have caused this glitch I'd be grateful. I'm willing to reboot my firewall a few times in the name of making this a better product!pfSense-Full-Update-2.1.1-PRERELEASE-amd64-20140221-1118.tgz fixes this for me - outbound connections now get sent to the default IPv6 gateway via teh PPPoE interface, not via re0_vlan10 (which is my "physical" interface that PPP packets arrive on.)
Hasn't fixed the IPv6 connections coming in from the internet, like email delivery or web browsing into my server yet.