roger that, thanks for the update!

I have found the problem! I accidentally added the fe80::/16 range to the EasyRuleBlockHostsLAN alias to avoid my pfSense logs being swamped with local traffic. This caused these packets to be blocked thus the errors to be generated. I have removed the fe80::/16 range from the alias and the problem went away. DHCPv6 and static mappings are working smoothly now :D

Hi guys, Hmmmm….does the auto-updater check 32 vs. 64 bit when it runs? I've changed over from 32 to 64 and I bet I still have the i386 update url set in my config! Now that I think about it that would explain a lot..I would have sworn I was running 64 bit which is why I updated last night. -Will

If you read the sticky when entering the board there is a nice tutorial linked from there on how to get your tunnel working. Google might find it too, yep, it does

OpenVPN with IPv6 is now supported. Configure the IPv6 networks on the OpenVPN Server settings page. Create IPv6 firewall rules on the Firewall Rules OpenVPN server interface tab. Install the openvpn installer with IPv6 support. http://www.greenie.net/ipv6/openvpn.html http://www.greenie.net/ipv6/openvpn-2.2.0-ipv6-savepasswd-20110522-install.exe That should be enough. Client support is limited to windows with the modified installer and any other that has the IPv6 payload patches integrated. I've contacted the Viscosity folks but it's not in the pipeline yet. They are aware of the patches though.

It works fine on either /64 or /128 for me now. Make sure to sync up with the current code before changing anything.

Yeah :) That way, works.

More fixes.

ok next weekend when i run a snapshot upgrade, I will also run the ipv6 upgrade as-well.

At the moment I'm editing the conf with textmate but I have also edited the file with Kod. I'm mounting the filesystem with an implementation of fuse called ExpanDrive so that I can edit and backup the file as if it were a local disk. The file doesn't seem to be corrupted, as I can read it back in after editing. Also, it gets reset when saving settings in the webconfigurator, as you noted. Perhaps there is something else going on, as I had a bunch of calcru went backwards error messages preceding a panic just now.

so what your saying is there currently is no fix?

thanks for the this response too let me know when it is added to the code thanks for everything!

Cino has it just about right. Once 2.0 ships the current ipv6 code from databeestje will likely be pulled in and used as the basis for 2.1 from that point. Obviously many other things will go in to make 2.1 proper, but that will be a good starting point to jump ahead on ipv6. The current ipv6 code is periodically synced up with 2.0 proper to make sure there isn't too much divergence between them. Many of us devs are running the ipv6 code on routers in various places trying to help track down issues. I run it at home on my router and use a he.net tunnel, it works great for me (aside from some dhcpd issues which have probably been fixed since my last sync.)

@billm: That's a horrendously large sync.  Looks like it has over 1100 changed files, I'm not totally surprised it's making Firefox cry (mine didn't die, but it certainly had massive issues rendering the page).  If it's any consolation, I'm reasonably confident that our Gitorious install wouldn't have been any happier with it. Gitorious would have just refused to show it entirely, "too large", so it loading at all is definitely an improvement. Gitorious had that nice habit of doing that to small diffs in some circumstances too. That page indeed takes a long time to load but that's just the massive amount of stuff there. Chrome loaded the page about 5* faster than Firefox 4.

@Kampfwurst: i got the same error. Is it possible to post the fix It still doesn't work for me, but I have added the IPv4 and IPv6 gateways manually. When I have the time I will do a fresh install and restore the configuration and see if it works better.

didn't know that, thanks for the info!

@billm: Should be fixed here: https://github.com/smos/pfsense-ipv6/commit/fed025ea776a0f8ec2a7b324c73dbac9c72a2c6d ha, you were faster. i digged in the code myself, and was just about to commit a patch myself, but yours is more clean than mine.  :D

Ok looks like reached max attachment size - had to create new post. This does seem a bit odd?  I looked at the total blocked ipv4 in after generating some ipv6 traffic, that shows as ipv6 passed in – this is odd.  Is this what your seeing?  See 3rd attachement [image: isthiswhatyourseeing.jpg] [image: isthiswhatyourseeing.jpg_thumb]

You're welcome guys :)

Yeah I saw that ;) hehehe Right place at the right time I guess!  Saw the fix right after I posted. Maybe I should play the lottery today ;)