why would you need to add that to pfsense routes?  If you want your vpn client to use the ipv6 tunnel to get to other ipv6 networks other than the ones you list then yeah you prob want to push that route to your vpn client

In the advanced box
push "route-ipv6 2000::/3"

@kobold:

Does this mean that after setting up the WAN interface / (re)boot, I always have to disconnect and connect the PPPoE twice?

Yes. And control the process with (kill -9 PID).

First time you will get rid of the "privateextension"-address (good), but there seems no proper/reliable cleanup of old PID dhcp6c. (bad). Therefore second time will assure you one valid PID on the proper fe80::, so to keep the hourly & mandatory 2-hourly lease renewal with ISP on fe80:"MAC".

FYI: something strange in Status-Interfaces(PPPoE) are the value's for Link-Local & Address. I would expect Address to be based on pfSenseBox-WAN-MAC and Link-Local on the pfSenseBox-LAN-MAC. Now it is both on pfSenseBox-LAN-MAC (!?). In 2.2.4 Address was based on pfSenseBox-WAN-MAC. Typical design question…

Oh, and work with forced MTU 1492 (WAN & LAN's).

<sarc>About need or grief or learning… Track interface. Once your refrigerator is aware with its MAC, it will talk to kaymart about the eggscontainer because you allowed RA assisted or unmanaged, SLAAC ;). And don't you love it, the 2-way audiovisual SmartTV. Nah, IPv6 will ease national security applications.</sarc>

ISP-native or cloudy GE-tunnel does it matter ?

I use IPv6 pfSense for explicit outbound allowance, so create static LAN's and use DHCP6-server an RA managed or just create static server(hosts) for LAN's...

Not that i have the all-knowledge of stuff tho, but this HAS been covered a lot of times before :)

Anyway.
1. You can ofc. have both ipv4 and ipv6 addresses on your gear. That way you will "always" be able to connect to the ipv4 address if that is a concern :)
2. If you do not want to use ipv6 at all, just disable ipv6 on the lan/wan interfaces + you can remove the check in the box under System -> Advanced -> networking : Allow ipv6 (That way, ipv6 is disabled throughout pfsense)
3. There are different ways of setting up ipv6 for your internal devices. Several posts here on the forum about timewarner and ipv6. The easiest "out-of-the-box" setup should be to set WAN interface to "dhcp6", and LAN interface to "track interface" on the ipv6 box. You may have to fiddle around with the prefix size (dont remember for timewarner). If that works, your internal lan clients will get their ipv6 addresses from your isp via pfsense prefix delegation (PD). This wont make for static ipv6 addresses, or you having a direct influence on who gets what address.

If you want to have static ipv6 addresses on your LAN, and use different network prefixes++ this can be achieved with running a internal dhcpv6 server and assigning addresses in a sense like you have with ipv4 although this is a much more advanced setup :)

If you want to setup the latter, im sure this has been covered in many posts on the forum aswell :) Hopefully you got a couple of answers even tho im by far any expert in the field. Please correct me if im totally off tho :)

C

I just want to say thanks to everyone who tried to help me on IRC and Reddit. I ended up solving this issue. The fix was to call up TWC and they changed my cable modem to put pfsene into bridge mode. Before I called them I had psfense in a "Pass Through" mode on the Ubee cable modem. I thought that was all I needed to do. With that setup I actually had a network on the cable modem and on pfsense. I also had an addition wifi hotspot coming from the cable modem.

Once TWC put the modem into bridge mode, I could no longer access the cable modem interface. Wifi stopped as well. However, my pfsense start getting IPv6 addresses for my clients on LAN!

Just in case anyone is wondering, the pfsense configuration is pretty much the same as in http://theosquest.com/2014/08/28/ipv6-with-comcast-and-pfsense/. I did also add a Firewall Rule to blcok all IPv6 traffic coming into LAN from outside of LAN.

I also changed the DHCPv6 Prefix Delegation size to 64. 63 didn't seem to work, but I might try again with 56 or some other number lower than 64 to get another IPv6 range for GWN

@empbilly,
Forget what you've been doing with IPv4 subnets.  The general consensus in the IPv6 world is that the "subnet" is no larger and no smaller than /64.
That leaves you with 64 bits of usable host addresses in a single subnet. 
To put that into perspective 64 bits = The entire world's Internet MULTIPLIED BY The entire world's Internet, and there would still be loads of addresses left over squeezed into a single IPv6 subnet.
Technically when using only SLAAC its less, but still >40 bits.
The only place where you'd see a netmask larger than /64 would be in the case of RA prefix delegation on a router where it is expected that other routers on the same subnet would take  the prefixes, again a /64, to use on one of their other interfaces.

Android devices support SLAAC tho.

Setting pfsense dhcp6 server to "Assisted" should make ipv6 come alive on the android clients.

C

Yes, but the point is why do I ever need this rule in first place, in order to get the ipv6 connectivity to work :-/

Thank you so much, it's working now :-)

Thanks very much dok!

You put me on the right track.  Problem was subtle, but makes sense now in hindsight.
I had stacked the SPF records, just as Google does, but if you put a "a" or "mx" inside the TXT record it is applying it to the fqdn of the stacked record, not the base record from which it was included originally.
So while I had _spf.example.org.  IN TXT  "v=spf1 a mx ip4:72.x.x.x ~all", the SPF parser was looking for an A and MX record in _spf.example.org, not in example.org which included _spf.example.org.

I've cleaned it up, folded mail6 back into mail and I'll give it another spin.  Strange though that it never has issues with IPv4 delivery, yet that is where the source of the problem lies.

You got an IPv6 address on the WAN side, but that won't do any good unless you also get an IPv6 address from a different prefix on the LAN side.
It looks as if the ISP isn't honoring the IPv6 prefix delegation request.

Well it is a tunnel so yeah going to be a hit to perfomance compared to no tunnel but i think the small hit is well worth the current advantages to is with most isp a mess the feature i would love to see isp do is assigned /48 or /56 or even a 60 with control of the ptr if u request

Gents,

I am still struggling with this.

I installed the cron package and added the line recommended by doctornotor.
However, the DyDNS-service provider did not receive any update, neither all 5 minutes nor at all.
The dynamic IPv6 on the router changed - and I lost connection to the PFSense again.
Rebooting the PFSense worked, it updated the IPv6 address with the DynDNS-service provider correctly.
Do I need to start cron somehow? I checked with the "top" command and cron is running. I also checked if the line is added in /etc/crontab. It is.

PFSense is obtaining its IPv6-WAN-address from the ISP router, it has DHCPv6 running.

I found this note at the bottom of the page to configure DynDNS-service: 
"Note:
You must configure a DNS server in System: General setup or allow the DNS server list to be overridden by DHCP/PPP on WAN for dynamic DNS updates to work."

Well, I have set the IPv4 address of the ISP router as DNS address. Do I have to add another DNS server, ie the ISPs IPv6 address of the DNS server?
Is it neccessary to specify a gateway on this page?

What the heck am I doing wrong here …?

Any inputs are more than welcome, I need to maintain several PFSense appliances on M-Net-DS-Lite lines. And they are installed in distant places and I have a hrad time to convince someone at the location to reboot these appliances all the time...

I am about to install a time switch at the location which turns off the power on the PFSense for one minute in the middle of the night to force a reboot (and thus get an update of its IPv6 address). But this would be really old-fashioned and anything but state-of-the-art....

Regards,

Volker

You have the "holy grail" for debugging - an environment where a problem occurs reliably.

Your commenting of the calls to /usr/local/sbin/ppp-ipv6 restores the pre 2.2.5 behaviour and proves this is a genuine regression, but that cannot be considered a "proper" fix. As I alluded to in the other thread, the old behaviour amounted to "fire off dhcp6c via rtsold and hope it all stays working", which is not necessarily true. pfSense prior to 2.2.5 took no IPv6 related actions when an established PPP link failed or when the link returned. This could lead to a loss of IPv6 connectivity when a failed PPP link was re-established.

The question is what is going wrong in your installations with the stock 2.2.5 code. When you can afford a little downtime, would you uncomment the calls to /usr/local/sbin/ppp-ipv6 and send me the output of the four debugging commands in the other thread? My guess is that there is a timing related issue that is leading to dhcp6c being started twice. If that is the case, I think the best fix will be to change interface_configure() in /etc/inc/interfaces.inc to stop it calling interface_dhcpv6_configure() when establishing a PPP connection. That way, the risk of interface_dhcpv6_configure() being called twice on initial PPP link establishment is removed.

Ultimately, a refactoring and tidying of the DHCPv6 related code might well be worthwhile for the sake of robustness.

I'm stupidly busy over the next six weeks, but I will try to keep an eye on this issue.

Thanks, fixed by removing the 4th field. radvd only allows 3 there.

Glad you found it.  Probably would have needed to see the System: Gateways: Edit gateway page to have spotted that.