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    *        *
…..

Check out the advanced options on limiters, you can set artificial latency (and loss) there, though that would affect the whole connection and not just the initial packets.

@cmb:

Checking "Allow IPv6" only removes the block all inet6 rules.

Understood!

Your allowing v6 would be on the tunnel, assuming WAN is your Internet connection with v4 only that has the 6to4 tunnel. In that case, your WAN only sees v4 traffic, and your tunnel rules would allow or deny v6 traffic inbound on the tunnel.

But my tunnel is part of the WAN page as you can see above.  So there are no "tunnel rules" to be had.  In fact I must built the rules on the WAN tab for them to be effective.

There aren't any rules permitting IPv6 other than what's user-configured.

I can guarantee that Ive made no rules to allow any IPv6 traffic of any kind from the WAN or any Tunnel side as Ive been working on this. In fact I reproduced it on my lab machine tonight.  The rules page I posted the shot of above is how I have things set up now. But without any of the v6 rules it readily passes the traffic.

I tried this also using DHCP6 on another machine and did not have the same findings.