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.

No. Not really. It was a while ago. Any current managed switch ought to be ok.

Still don't like the mixing of tagged and untagged traffic through.

True, IPv6 can be daunting at first, but the reality is that the most basic networking principles from IPv4 still hold; the Layer 2 part hasn't changed, you can't have the same subnet on two interfaces on the same box (except fe80::/10), you have to have routes to get your traffic from point A to point B.  Oversimplified, but that's the gist of it.

Here are a couple of IPv6 links to get you started…
Hurricane Electric Free IPv6 certification - you'll get a free T-Shirt for completing it: https://ipv6.he.net/certification/
Fred Bovy has a copious amounts of slides, videos, etc http://www.slideshare.net/fredbovy/fred-explains-ipv6

I updated to the 2.2.5 version, but there was a problem regarding mounting of the partition.

Error: Mount from ufs:/dev/ad0s1a failed with error 19.

After some research could solve with the command below.

ufs:/dev/ada0s1a

From what I gather, the new FreeBSD 10.* changed the names of the partitions.

After that updated the fstab for the new partition alias.

–-------------

Now I will analyze the IPV6.

I thank everyone for the help!

@gst.freitas:

however in the console is / 128

And it should remain so. Required because it's point-to-point. Leave the thing alone.

Awesome, it's static.

My thinking then is that they haven't routed the remainder of the /64 anywhere, just sort of lumped it on me.

I'll drop them a line :)

See also https://forum.pfsense.org/index.php?topic=101417.msg565853#msg565853

So with this config file

interface em0_vlan3 { #      information-only;         send ia-pd 1;         request domain-name-servers;         request domain-name;         script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please }; id-assoc pd 1 {         prefix-interface em0_vlan5 {         sla-id 1;         sla-len 0;         }; };

It works. I get functional IPV6 on my router, however pfsense doesn't seem to want to let me advertise this to clients on my lan.

Also, there seems to be no choices/combination of options to do PD on a normal WAN interface. in the 2.2.5 changelog, it said IA-PD changes were made for PPPoE users.

@hda:

You should be able to make LAN as 2001:2060:f4:e::1/64, all the 2001:2060:f4:e: numbers should be yours.
[The last 64 bits are required reserved for any host on the LAN, SLAAC or DHCPv6 or Static.]

Your gateway for the LAN is obviously 2001:2060:f4:d::1/64
Look in System: (routing) Gateways for your correct route.

For Static on hosts use RA + Router Only
For DHCP6-Server (range in last 64 bits) use RA + Managed (be sure to NOT check bogon networks on Interfaces:LAN)
For SLAAC from hosts use RA + Unmanaged

Everything works now. Ports are reacheable though IPv6.

Final routes can be found from the attachments.

You may do an traceroute6 to mail.sami-mantysaari.com to check. :)

final_IPv6_routes_pfSense.JPG
final_IPv6_routes_pfSense.JPG_thumb
final_IPv6_routes_mail.JPG
final_IPv6_routes_mail.JPG_thumb