It looks like I got it permanently fixed, my mistake was to boot up my PC "too early" when the firewall was not yet ready (I shut down the firewall and the PC when I don't need it). For some weird (or not weird) reason my PC didn't get any IPv6-address, it kept sending solicit messages according to the DHCP logs, but never sent a request message… After rebooting my PC, according to the logs it sent a solicit message, after receiving the advertise from the firewall it sent a request and got a reply with an IPv6-address and now everything is working... (so I guess it was a layer 8 error...)

Thank you!

I installed the alpha from 17th of April just now. 6RD is still not working, but it does not seem exactly the same either. A few examples: A promising log entry: php: rc.bootup: ROUTING: setting IPv6 default route to 2a01:79d:3e85:a408::213.167.115.92 But: wan_stf is gone from ifconfig, and no ipv6 config apart from fe80 (local link) addresses are seen. The IPv6 address is gone from status | dashboard | wan. These two last problems are probably related to 6rd failing on creation, I have posted this issue in https://forum.pfsense.org/index.php?topic=75707.0

OK, quick update. Previously, the LAN interface was not getting anything but the link-local IPv6 address, but after a reboot, it's now getting a /64. Machines on my LAN are also now getting addresses within that /64, so this issues seems to be resolved. Thanks again.

Bumping to see where I can resolve this issue. As a lark I install m0n0wall and setup IPv6 there. PD allocation worked, yet still no LAN traffic passing the local netgear modem. But when I did enabled IPv6 on the LAN interface, the link-local always stayed in EUI64 format. So just trying to figure out what portion of pfSense code is changing the link-local addresses to fe80:1::1:1, and how to revert back to SLAAC-style addresses.

@adler187: After changing the 'gif tunnel local address' to the IPV6 local address on the GIF and setting IPV6 to None on the interface, I got things working. Yes, that is how it should be. :)

You are indeed wrong; this is perfectly normal for IPv6. Typically an IPv6-enabled host will have a SLAAC address (generated from the NIC's MAC), a temporary address (IPv6 privacy extensions), and possibly a DHCPv6-assigned address on each v6-enabled interface, plus link-local addresses. For privacy reasons, the temporary address is what will generally be used for outbound connections (which is what those websites will see); however, you should still be reachable at the other addresses for inbound connections.

Yes, thank you. That's where I went wrong. I see it now.

Can't really tell you what it means.  But, I can tell you how to clear it up. Shutdown pfSense and power off the cable modem. Power on the CM and wait until it syncs. Boot up pfSense. The errors will be gone.

Probably the DUID.

The problem seems to have been resolved in 2.1.1, as the tunnel now works without setting the default gateway. The manner in which the OPT-interface can have its IPs set has changed from 2.1 to 2.1.1

Thanks to everybody and apologies, I am restarting all configuration from scratch (I did not finished yet, but I believe I am on the right way). Anyway I think the many changes I operated stratified badly compromising somehow the final result with unreasonable results. Should I get in trouble again I will provide more details. Thanks again and regards Dario

Can you show you anonymized /tmp/rules.debug?

Just delete your gateway on system routing.

"And if not, can you have multiple VMs bridged to the same NIC and using different addresses (either in a v6 world or v4)?" You can bridge as many as you want to be honest..  Why do you think you need nat in VM setup?

Normally you have to use NAT for this. It is very dependant and error prone to change prefixes like that on failure. That is because definition of failure is very vague. Also presently there is no way you can follow(track6) 2 different WANs in pfSense.

same here. however, I tried both pfSense and OpenWrt. both of them do that. so I think it might be the ISP side. I'm using TWC in NEOhio area. I did a tracert to google.com.  first hop responsed very quick(it'm my wan ip), then lots of responses and timeouts 2    *        *        *    Request timed out. 3    9 ms    *      10 ms  2605:a000:0:4::2:22b 4    15 ms    9 ms    10 ms  2605:a000:0:4::2:4dc 5    *        *        *    Request timed out. 6    *        * …..