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. :) [image: final_IPv6_routes_pfSense.JPG] [image: final_IPv6_routes_pfSense.JPG_thumb] [image: final_IPv6_routes_mail.JPG] [image: final_IPv6_routes_mail.JPG_thumb]

Technically, there is no limitation to the number of interfaces that a system can have with the same link-local IP.  https://tools.ietf.org/html/rfc4007#section-5 This is because the interface's name must appear in it's use in order to select it. ie: ping6 fe80::dead:c0de won't work because it won't know what interface to use.  You must use ping6 fe80::dead:c0d%em0. That being said, FreeBSD 10.2 is perfectly happy with 3 interfaces configured as fe80::1, besides lo0 is also fe80::1. [image: fe80-1.png] [image: fe80-1.png_thumb] [image: fe80-2.PNG] [image: fe80-2.PNG_thumb]

This sounds like Redmine #5297. I've developed a fix, which is in recent 2.2.5-DEVELOPMENT snapshots. If this solves the problem, please comment on the bug to reference this thread and say your problem is fixed.

Get /48 from HE and move on. The idea of splitting /64 is completely broken.

@modem.over: Its not in 2.3-ALPHA  yet.  Will keep an eye out. I think the big push on 2.3 right now is the web UI more than anything… I would imagine it will come sometime after that's all taken care of.

@awebster: Sounds like there is another device on your LAN segment that is wanting to be a router. Indeed. radvd is telling SharkBit that another device is advertising a DNSSL local domain and O bit that are different to those being advertised by pfSense. If pfSense is the gateway, the announcements from the other device (whatever has the link local address of fe80::feb5:8fc9) should be disabled.

upon further testing, this is unrelated to ipv6.  It looks like it has to do with stable table tracking.

Well, enjoy breaking your IPv6 by blocking ICMP. Not really sure what to say.l