Trouble setting up an IPv6 tunnel (Hurricane Electric)



  • Hey,

    for the last couple hours now I've been trying to get the HE IPv6 tunnel working without avail. The gateway appears to be down and traceroutes / pings just time out (on the pfSense box itself). Maybe someone of you guys could help me. Please?

    This is the tunnel:

    Client IPv4 Address is set to the correct interface's WAN IPv4 address (I've checked this regularly).
    Note that I didn't censor the a/b and the last digit of the IPv6 addresses, so you still can tell them apart.

    Here's what I did and what I expected to be enough to get the tunnel working:

    1.) Created a new GIF port.

    2.) Assigned it to a new interface.

    3.) Enabled the interface and changed its name.

    4.) Created a new rule to allow all the ICMP traffic.

    Once everything works I'll try to specify the source address, but as for now this should do the job.

    5.) Made it so one of the OpenDNS IPv6 addresses is used to monitor the interface.

    And this is what I tried in despair:

    1.) Double checked the gateways.

    2.) Set the "Default allow LAN IPv6 to any rule" to use the new gateway.

    3.) Basically disable the firewall on the tunnel's interface.

    4.) Rebooted.

    Still the first page looks like this:

    Also System > Advanced > Networking > Allow IPv6 is checked!

    Any ideas?



  • In step 3), try setting the "IPv6 configuration type" to "static IPv6", the "IPv6 address" to the "client IPv6 address" from HE, and the gateway to the "server IPv6 address" from HE (not "dynamic" as in your step 5)).



  • @razzfazz:

    In step 3), try setting the "IPv6 configuration type" to "static IPv6", the "IPv6 address" to the "client IPv6 address" from HE, and the gateway to the "server IPv6 address" from HE (not "dynamic" as in your step 5)).

    Thanks for your answer. I did exactly as you instructed me to, but unfortunately the results are the same: I can't even ping any IPv6 hosts from pfSense (Diagnostics -> Ping). The logs don't reveal anything new as far as I can tell.

    Because I'm running pfSense from within a VM, I replaced it temporarily with a VM running Debian, just to narrow the problem down a bit. I was using the settings HE themselves provide:```
    auto he-ipv6
    iface he-ipv6 inet6 v4tunnel
            address 2001:470:XXXa:XXXX::2
            netmask 64
            endpoint 216.66.80.30
            ttl 255
            gateway 2001:470:XXXa:XXXX::1



  • Did you set the VM networking to bridged mode?



  • @razzfazz:

    Did you set the VM networking to bridged mode?

    I don't think so. I don't think I even understand.

    I got three WAN interfaces and one LAN interface. The LAN interface and two WAN interfaces are connected to virtual switches. That's because those two WAN interfaces connect to the same gateway, which seemed to confuse pfSense. So I decided to use lightweight linux VMs to double NAT. That shouldn't be of any problem, tho, because I use the third WAN interface as the parent interface for the IPv6 tunnel. This one is connected directly to the DSL modem that my ISP provided me with. Also I enabled passthrough for this adapter. Here's a simplified network map..



  • Pass-through as in VT-d? 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).



  • @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!


Log in to reply