Still no luck. I just updated to yesterdays build.

I hijacked http://forum.pfsense.org/index.php/topic,56880.0.html to post more information.

fix the array (remove the bad drive from the array and readd) as described at http://doc.pfsense.org/index.php/Create_a_Software_RAID1_%28gmirror%29 and then you'll have no issues updating.

Can you run a ping -S $WAN_STF_ADDRESS $monitoring address and see if that works?

I'm seeing the exact same thing. Low level tests work fine, but http is very hit or miss. Ipv6-test.com almost never works, and with test-ipv6.com sometimes it's great, sometimes it's terribly slow, and sometimes I fail the large packet tests. Ipv6test.google.com alternately tells me I don't have any ipv6 or that it's working fine. As more "regular" sites are starting to be v6 enabled I've actually disabled my HE interface since I've grown tired of the timeouts just clicking on links for leisure surfing.

I'm on the March 12th build of 2.1.

@Sn3ak:

I too had this problem, however I saw another post, and found clicking save on the He.net interface, fixed the issue, however on reboot it came back.

My solution to the problem, was to change the recommended /128 subnet on both sides of the tunnel and made it a /64 as He.net specifies.
Multiple reboots later, it's still coming up automagically and working.

Hope this helps..

Mine survived a reboot, and then the update to the next nightly just fine once I "edited and saved" the gateway again, although I've always been using the /64 CIDR.

Did you always have the issue with the route dropping? Or was it after a certain update?

Free text config area sounds like a good idea.

As the saying goes: patches accepted :-) (or, preferably, github pull requests)

So long as the new functionality doesn't break the old functionality, it's all fine.

I haven't had time/funding/drive to work on this yet, but if someone else does, feel free.

What brokendash said is right.

Make yourself some /64's out of the /48 and use them as you did the first routed /64 they gave you.

You have 2^16 (65,536) /64 networks to use inside that /48. Don't spend them all in one place. :-)

IPv6 support exists is in the 2.1-beta version.

A linklocal address is fine, mine is 
fe80::201:5cff:fe31:da01

And working just fine - can your clients ping an ipv6 address on the public net, say ipv6.google.com

If so then your all good.  Is your pfsense lan getting a 2601: address?

Ok it was 0, I have deleted that and is now blank and rebooting.. Lets see what I get back on reboot.. Will edit post once it finishes reboot.

So I changed it to blank and got NOTHING now for lan ipv6 other than linklocal

And file is now

interface em1 {        send ia-na 0;   # request stateful address        send ia-pd 0;   # request prefix delegation request domain-name-servers; request domain-name; script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please }; id-assoc na 0 { }; id-assoc pd 0 { };

Again – changing it back to 0 and rebooting again.

So once I changed it to 0 before reboot when I look at status for lan I showed this again
IPv6 address 2001:558:6033:12c::1

edit: ok after setting back to 0 on lan interface and rebooting I am now getting
IPv6 address 2601:d:8b80:c0:250:56ff:fe00:2

Again -- this is working, but pretty shitting address for your gateway ;)  Why would it be such an address and not like 2601:d:8b80:bf::1 where it was before?  I would think the address should be 2601:d:8b80:c0::1

OK, well then next time you get a chance, try it. If we don't get better info on how it broke, it will never get solved.

Did clean install with today's snapshot 1/29. Seems to be working fine now. Not sure what was the problem with 1/28 snapshot.

It could be possible in the future if we discover some sort of "proxy NDP" type daemon for FreeBSD that would arbitrarily respond to NDP requests for an entire prefix.

IPv6 really doesn't like NAT though. The intent was to route everything as much as possible and do no NAT.

It has been requested, and there is a chance we may do it for 2.2, but it won't be in 2.1.
http://redmine.pfsense.org/issues/2358

Ah, yeah I see.

Well when you do ping6 with -I it does that, but not with -S.

If you use -S (ip) then it will send it the right way, but the error is usually a bit different.

: ping6 -I em0 www.google.com  PING6(56=40+8+8 bytes) 2001:xxxx:xxxx:xxxx::1 --> 2607:f8b0:4003:c01::69 ping6: sendmsg: No route to host ping6: wrote www.google.com 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote www.google.com 16 chars, ret=-1 : ping6 -S 2001:xxxx:xxxx:xxxx::1 www.google.com    PING6(56=40+8+8 bytes) 2001:xxxx:xxxx:xxxx::1 --> 2607:f8b0:4003:c01::69 16 bytes from 2607:f8b0:4003:c01::69, icmp_seq=0 hlim=57 time=69.442 ms 16 bytes from 2607:f8b0:4003:c01::69, icmp_seq=1 hlim=57 time=66.597 ms

IPV6 definitely works for a single endpoint and has worked now for over a year with a directly connected Linux boxes that doesn't have a firewall between it and the ISP.  Works fine on a windows XP box as well.

It is time to go find someone at the ISP to talk to.

Thanks again for all of your replies.

Just to make this clear, you can do this, but you will lose SLAAC. And thus computers will no longer auto configure a IPv6 address.

Ofcourse setting up RA combined with a DHCP6 server will make this work, provided that all clients support static addressing (yes) or DHCP6 (no).

Don't expect your phone to whizz into IPv6 action.