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.

@ghsmith: POSTSCRIPT: I am having a minor problem. In the above configuration, if I modify any aspect of the LAN interface in the web configurator, I loose all IPv6 connectivity until I reboot. I think this is because the router advertisement daemon (radvd) dies when I "apply changes". Ya, that is a problem, without a solution that I know of.  Making a change, or dropping the link on the LAN interface will do it too. FWIW, I'm on 2.1.1-PRERELEASE  (Mar 7) and the problem is there.  I restarted the switch pfSense is connected to just today and the LAN lost it's IPv6 prefix.  Only thing I could do to get it back was reboot pfs. REPORTED HERE:  https://forum.pfsense.org/index.php/topic,73492.0.html

There is no such feature with IPv6. Read: NOT implemented in the DHCP server. Also read RFC 6939. BTW, here's a nice quick summary slideshow on DHCPv6 state/implementation/pitfalls.

Atlantisman: I know this might not be much, but I might have some info you can use. Well, first of all, try to take whatever IPv6 (global unicast) address e.g. your computer might have within your google routers IPv6 network. Then visit e.g.: http://ipduh.com/ipv6/whois/ or https://www.ultratools.com/tools/ipv6InfoResult And then copy/paste your IPv6 address and see what subnet prefix (length) you get returned (as well as your ISPs /32 route). Now what is interesting is if the subnet prefix is e.g. /48,  /56, /60 or something else. Because even though the google router might give your LAN a /64 prefix it is probably to let SLAAC work. Your actually provided network might be larger e.g. a /56 subnet prefix. What you then could do is to setup your pfsense box manually without any fancy configuration but where you just configure your WAN address to be the wan address of your google router (even though you are not going to use the google router of course) Your google routers WAN might have a /64 subnet. But the actual provided network to you might be larger e.g. /48 or /56. If you are not provided with the WAN address e.g. by a google manual or a web interface then simply try to: traceroute6 google.com The first print out is likely the address of your own router/the google router (your LAN subnet). Then right after this subnet the WAN address of your WAN gateway (not your google router, but the gateway your google router uses) is printed. It might have an address that ends with ::1. Then you are likely to use the same subnet address, but instead it should probably end with ::2 - anyway it does not matter a lot if the WAN subnet is /64 - but it could be /127 - in that case i am not sure how well pfsense works. (pfsense 2.1 does not seem to support /127 addresses when configuring static routes on the LAN site - but that is a whole other story.) Thereafter try to setup your LAN. Now if you want to use SLAAC in your LAN you have to use /64 prefix which means you limit your network e.g. if the entire network provided is e.g. /48 or /56. But anyway - you can try to see if it works taking the lower /64 part of the larger network. If it works you can try to take the next /64 prefix and see if that also works and let you have traffic route out and into your network. Remember to set https://your_router/services_router_advertisements.php?if=lan (Services DHCPv6 Server/RA - Router Advertisements) to either Managed or assisted (depending on what you want). Else you might want to use wireshark again on the WAN interface but this time searching for http://wiki.wireshark.org/ICMPv6 ICMPv6 packets regarding http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol#Technical_details . If some of it works then fine else try to see if your google router has a web interface (located as the default route address - perhaps some:address::1 ) with some configuration info. E.g. if the google router uses PPP. Actually here is a site that has a PPP example with ICMPv6 with a screen shot from something that looks like wireshark: https://sites.google.com/site/amitsciscozone/home/ppp/ipv6-ipv4-over-ppp Hopy you can use at least some of it :-) Cheers Anders

@bruor: …. This almost seems like a routing issue.  If anyone can help suggest ways to narrow this down or find any changes that may have caused this glitch I'd be grateful.  I'm willing to reboot my firewall a few times in the name of making this a better product! pfSense-Full-Update-2.1.1-PRERELEASE-amd64-20140221-1118.tgz fixes this for me - outbound connections now get sent to the default IPv6 gateway via teh PPPoE interface, not via re0_vlan10 (which is my "physical" interface that PPP packets arrive on.) Hasn't fixed the IPv6 connections coming in from the internet, like email delivery or web browsing into my server yet.

Give a try with a snapshot from late tomorrow since behaviour should be improved.

Never mind. Apparently apinger was restarting after being stopped. Just disabled it for each of the gateways and all is good now.

Happy to hear it worked out in the end :)