@razzfazz:

Pass-through as in VT-d?

Yes, Intel VT-d aka DirectPath I/O in VMware ESXi. The parent interface's name is "igb0". In contrast, the other two WAN interfaces were called "vmx3f1"/"vmx3f2" on pfSense 2.1 and are now called "vmx1"/"vmx2" on 2.2. By the way, I've switched from 2.1.3 to 2.2 since my last message in this thread.

@razzfazz:

The point is, the WAN interface that's the parent for your tunnel cannot be behind a NAT (including the NAT that many desktop virtualization solutions use for their virtualized interfaces by default) unless you set up the correct forwarding (proto 41 – note, not port 41! – needs to be forwarded to your tunnel endpoint).

There's no NATing going on anymore (for the tunnel's parent interface at least). After your post I've set the upstream DSL modem to operate in transparent bridge mode and let pfSense do all the PPPoE magic. pfSense displays the exact same IPv4 address on that interface that various "What's my IP address?"-websites show me (like this one). Now that I figured I needed to use the "Update Key" instead of my password, pfSense's DynDNS client seems to work just fine, too. HE is constantly aware of any IP address changes. The tunnel is still not up however. :-X

Edit: It's working!
Well, after deleting my old tunnel and creating a new one and updating all the settings in pfSense accordingly I was finally able to ping servers via IPv6, but unfortunately most of the requests simply timed out. I stumbled across this video on youtube suggesting to set the MTU to the lowest possible value. So after setting the MTU to 1280 in pfSense and the HE control panel I got rid of that odd timeout problem.

Still, I noticed some minor flaws:
1.) Gateway monitoring is stuck on "pending", no matter what I set the monitor IP to. (I just disabled monitoring for now.)
2.) A second/bogus GW popped up that I simply can't remove. It doesn't show up in exported settings, but as soon as I import the settings it's there again.
3.) The box on the right side of the tunnel interface on the first page of pfSense is blank where it should show the IPv6 address I assume. This behavior doesn't change whether or not I set "IPv6 Configuration Type" to none or static, providing the IPv6 address myself. Fixed as per 2.2-ALPHA (amd64) built on Fri May 23 08:08:31 CDT 2014!

However, thank you for your time razzfazz!

Am I alone with this ?

I played with the Pool and the Router advisement but no luck so far… any help ? Please

I set the MSS to 1000, and then it started working.
No idea why it has to be so low, and it could probably be a bit higher, but I haven't been bothered to check.

@priller:

1e100.net is Google.

Correct. See: https://support.google.com/faqs/answer/174717?hl=en

Yeah, for android devices is a must, they only use SLAAC.

Hey, thanks for the replies. I'll look into setting it up as a transparent firewall.

Thank you podilarius,

I've turned off the default logging in the logger settings and do not see anymore ipv6 anything logging - which is what I would prefer.

@Criggie:

@Criggie:

I think this redmine bug is going to be related:    https://redmine.pfsense.org/issues/3357

Turns out that bug was not related.  Here's the current bug report for this  https://redmine.pfsense.org/issues/3544

SOLVED!  I don't know when the option appeared but under interface -> WAN there is now an option

Use IPv4 connectivity as parent interface  [X] Request a IPv6 prefix/information through the IPv4 connectivity link

So now I have full IPv6 native connectivity both inwards and outwards.

you filed it as a feature request, not a bug.. Its a BUG not a feature if dhcpv6 is running when your using dhcp-pd but you can not edit its config or even view what its handing out that is a bug not a feature ;)

Well, as pointed out before, using the same /64 on both the WAN and the LAN interface won't work, and since all you get is a /64, splitting out a sub-prefix will be problematic as well (IPv6 is really designed to use /64 as the maximum prefix size for LAN use; things like SLAAC will not work with anything longer). So, not sure what to tell you at this point.

Hi guys,

So can anyone give me some idea where I should change the gateway to wan_stf as ermal suggested earlier in the thread? I'm stumped trying to find it and it's killing me thinking that I could be one single setting away from working 6RD on 2.1.2!

-Will

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.