Thanks David

Do I still need to tick the DHCP6 Client Configuration option

Request a IPv6 prefix/information through the IPv4 connectivity link

A quick try just now seems to indicate that I do but want to make sure that not because i'm still doing something wrong when I don't tick it

"Request a IPv6 prefix/information through the IPv4 connectivity link" should be selected. From memory, this should always be selected for native IPv6 over PPP.

Just an update on this:

My IPv6 connectivity is still broken. I had contacted support about getting static route support put into my account but apparently it was done when i regraded last year.

Tried with a fresh pfSense config (both 2.3.3_p1 and a 2.4 nightly): no success.
Tried with a different router (Ubiquiti Edgerouter Lite): no success.
Zen rebuilt the IPv6 section of my RADIUS account: no success.

If i do a packet capture of my WAN i can see pfSense sending a DHCP6 SOLICIT but it never receives a response.

This morning i reinstalled pfSense 2.3.3 and noticed that it was very slow to update to 2.3.3_p1, so i did a 'dig' on the pfSense update server address and discovered it was dual-stacked. This led me to SSH into pfSense and attempt to telnet to port 80 on my own, IPv6-enabled, website. It timed out.

I now believe there's some firewall on Zen's side that is allowing ICMP6 traffic to and from my router but blocking other types (which would also explain the lack of prefix delegation, as it's requested over UDP).

IPv6 connectivity has finally been restored.

The problem wasn't at my or Zen's end but somewhere in the Openreach network. An engineer was dispatched to the VDSL2 cabinet and things started to work again.

I don't have any more specific details than that but thought i should post in case someone else ever experiences this bizarre problem and is searching for a solution (i'm on an ECI cab in case that's relevant).

Support from Zen was excellent and they very accommodating of the best time periods for me that they could take my connection off-line for testing things on their end.

That's good news. Are you now able to use a static IPv6 configuration on pfSense using the information I provided in this thread?

Yes, static IPv6 config setup and working fine. Thanks for the info.

This is really interesting.

I'm also connected to an ECI cab and have a similar problem. When I hit my line with 30mbps worth of 'failing' ipv6 traffic, that doesn't come out of the other side of zens bridged modem, I still see an increase in latency of ipv4 traffic. CPU utilisation doesn't increase on zens modem so it indicates the traffic is dropped by the cab.

Some IPv6 packets come through fine.

http://forums.thinkbroadband.com/zen/4460121-ipv6-sm...

It's never worked, after Zen suggested I buy my own VDSL modem to replace theirs I just gave up and went back to tunnelling.

I've been following a AAISP fault that looks similar too.

https://aastatus.net/2351

Maybe there's a problem with some versions of the ECI cards and IPv6.

Do you have a problem with PMing me your fault ref so I can try again with Zen to check if my line has a similar issue?

Edited by deleted (Sat 20-May-17 12:01:38)

Hi David,

I've been working with Kevin on various methods of getting his dual WAN system to work. The issue he has is that whilst DHCP6 would work fine on both interfaces, pfSense in its current state cannot support that, the reason being as I'm sure you're aware is that dhcp6c is set up as a single client with one port, without major rework to interfaces.* it's not going to play. I have started on creating a new mode for pfSense whereby you can specify manually the command line for dhcp6c this allowing two ( or more ) wan interfaces to be specified, this would be the correct way of doing dual dhcp6 WAN interfaces, and we will be trying that path over the next few days,

Now, I have also had some success in setting up static IPV6 on the ZEN interface, the only thing that will not play ball is the gateway monitor.

It appears that the functions that launch Dpinger do not allow for the fact that you can set-up a static IPv6 address on a PPPoE interface, and keep trying to launch Dpinger using the default WAN interface, i.e. igb0.

You obviously have some experience with pfSense, would you be prepared to 'play' with Kevin and myself in trying to resolve the static method?

marjohn56 is an excellent developer, I suggest taking up his offer.

Sky did mention in a uk ipv6 conference video that there is ipv6 issues on ECI cabinets that they have worked around, but its logical to conclude that all other isp's have worked around the issue as well.

I'm quite busy at the moment, but I'll do my best to help out. I'm always interested in trying to improve pfSense - and the IPv6 code is ripe for further improvement.

I know you're already active in pfSense development, so it would be both inappropriate and redundant for me to give you a primer on pfSense development best practice. I just wanted to encourage you to consider opening a Redmine ticket for this issue if you haven't done so already. Documenting the issue in Redmine can be helpful for everyone.


I haven't kept fully up to date with the dhcp6c and IPv6 changes in the master branch of pfSense which is, of course, what any improvements need to be based on. It may be that you need to address the architectural concerns I've previously noted in pfSense Redmine #5993-15 as part of your suggested feature if the refactoring I suggested there has not yet taken place. Unless your changes apply relatively cleanly to RELENG_2_3, I would think seriously whether it's worth the effort of backporting them considering the limited life remaining in that branch and that pfSense 2.3 is almost certainly closed to new features anyway.

I'm @davidjwood on Github and you can always PM me on here. I'm perfectly happy to spin up a virtual machine to test anything you come up with; I can easily reconfigure my switches so that the VM has access to my WAN connections rather than the rack server than ordinarily runs pfSense here. I'm also happy to offer what input I can to the development process.