sorry, the 6rd settings on the wan don't do anything yet. I have not written back end code for it yet. Hoping to get round to that soon. We might need to release 2.1 without 6rd. We also need more work on the 6rd patch for freebsd to make it work. at this point we have access to a test box we can work on so we're good for now.

Yeah all IPv6 issues (at least for now) belong on the IPv6 board. I didn't notice you already had a similar thread here in the IPv6 board until after I moved it. I'll just lock this one out in favor of the other thread.

It is there just may not be any snapshots for that yet. We are trying to make things work properly for 2.1 on FreeBSD 8.3 and PHP 5.3, so things are in a bit of flux right now. It's in active development.

gitsync can be hit and miss on nano. You can try it.

Ah, well to be fair, NPt does work for the traditional carp setup. Which is what I originally developed it for. Both pfSense nodes need to be able to access both networks, NPt works fine that way no different from the NAT we have today on v4. So just like you do with v4 multiwan and carp, both nodes share a single external and internal carp address on each WAN. Then NPt works fine. So tunnels, ehm, no. Not being able to disable RA is a bug. I need to fix that then.

Please see http://forum.pfsense.org/index.php/topic,45692.msg238924.html#msg238924.

I read that blog post but DHCP6 with prefix delegation is by far the easiest to centrally administer. DHCP6 has prefix delegation so that all those devices, regardless how they connect can get a globally routeable network prefix assigned to their lan. And more then 1 is going to be the default. This means that your wireless can use a different prefix from your lan, and everything would still work fine too. If you daisy chained routers, as some people do, it would create a double NAT, but with IPv6 and DHCP6 hierarchy would be maintained and subnetworks would still get a global network prefix. And DHCP6 works on everything because it uses link local addressing and not the ARP we used before. This means that yes, you could even get a delegated prefix on your laptop tethered to your phone using it's 3G.

Do understand that VOIP traffic will break just as it did before, because the protocol saves the IP address(es) inside the voip packets. Only protocols that store the actual host address inside the packets will break, just as they do in a v4 NAT.

Hi Guys, @cmb: There will be public snapshots in the near future. We're going to 6 month release cycles with far fewer changes in between, 2.1 is slated for mid-March and won't add much beyond IPv6. There is a 2.1 board now. That a lot of good news, thanks a lot! I think i can wait a few month for the 2.1 Snaps, i was just not sure if it will take as long as 1.2.3 -> 2.0 ;)

Joe_cowboy I want to thank you for your fixes!!!!  And hopefully see more of your contributions, sounds like your part of the team now if your code has been merged into the master branch?? I am quite sure there is quite bit of clean up that could use your scrutiny. So you mention bind – I would be very interested in anything you could do to implement bind into pfsense..  I do like unbound and the work being done in that direction...  Its a great product for most scenarios where pfsense would be used..  But then again I would much rather run a full bind product for my dns where I have full control and can have duplication of dns services where one box is master and another slave, etc. I keep wanting to move to the full bind running on my pfsense - but since its not actually a package its kind of a road block... I have munin running giving me stats on my unbound running on pfsense - it would be sweet as hell to see full bind as an option with stats in an rrd, etc.. Is that somthing your interested in doing???  I would sign up for sure as your #1 beta tester ;)

moved this over to the IPv6 board where it may get more attention from those of us who use v6. One thing with IPv6, it reduces the usefulness of country-restricting. It's easy to get free IPv6 space in many different countries from a number of different tunneling providers. Though not that country restrictions ever stopped any targeted attack, one can just as easily own something in another country on v4 and route through it. It's great for blocking various abuse, but not targeted attacks, and v6 lowers the barrier for bypassing such measures. Are you also doing v6 bogons? Same as my comments on the v4 bogons thread for that, we're fully dual stack with AAAA's for all our A's in our primary datacenter (95% of what we host). I would be willing to at least toss in a block rule right above our default deny to see what it would have blocked that we're blocking anyway, as an initial test. We're also using Cymru's list for v6 bogons, auto-updated far more frequently than we've needed to update v4 (including 6+ years ago when there actually was a changing Cymru v4 bogons list).

Although Hurricane Electric have free resolvers available for IPv6, these are often slow and returning results in seconds instead of milliseconds. Google now has IPv6 DNS servers available too. 2001:4860:4860::8844 and 2001:4860:4860::8888 http://code.google.com/intl/nl/speed/public-dns/docs/using.html OpenDNS does have resolvers available too: 2620:0:ccc::2 2620:0:ccd::2 But these are as of january 4th 2012 not running the full service including malware filtering. http://www.opendns.com/ipv6/

Thanks jimp for fixing that! It is strange since my crontab has the rc.update_bogons.sh running once a day, …although each time the rc.update_bogons.sh script is run, it has the initial sleep plus each section has an additional relaunch and sleep in it for a total of 4 relaunch and 5 sleeps if it has major problems... Such as if the WAN interface is down, or some other problem such as md5 (weird i know). maybe an exit 1 should be called after the first relaunch so that it doesn't relaunch up to 4 times/script and start a relaunch cascade!

Reading your diagram that the isp gave you, it looks like a normal static ipv6 configuration. Basically you configure the ::2 of the /126 prefix on the pfSense wan interface. You then create a gateway to the ::1 address of the /126 subnet. Normally the isp router will reply for ndp requests for this address. You can configure the 1st /64 prefix on the lan interface. Your isp will just forward the /64 networks to the ::2 address of your /126 subnet. This really is a basic static config as long as both the isp and pfsense reply to ndp requests. Which i think they will. If you have any questions or want me to review your configuration i can verify it remotely.

there is a bug in the current ra config mode where it does not set the right mode. That is still open for fixing. The IAID will have to be saved into the config.xml to make sure it persists, not sure why it needs another file unless the clients needs to have it that way. Also, I will likely pull the wide client and move to the ISC dhcp6 client at some point. Atleast before 2.1 is released. That client supports configuring a "pretty" ipv6 address on a prefix delegated. e.g. <prefix>::1 It's not that dhcp6 server is not a priority, but I'd rather get cascading prefix delegation working.</prefix>

Yes, please add the IAID field and I'll be glad to do the testing.  As I say, I'm currently testing against an MS DHCPv6 server and I think there is an inherent incompatibility between the two distributions which may or may not have to do with the server receiving FQDN and vendor class options from the client.  I'm using Wireshark to sniff and I know the Solicit message is being sent.  I've already tested the DUID and IAID functionality with FreeBSD clients and I know those fields are showing up in the right places in the Solicit.  But the MS server does not Advertise in response.  At least, no Advertise shows up in Wireshark as it does when Solicited from a Windows client.  Strangely, though, the DHCP statistics displayed by the MS server always show an equal number of Solicits and Advertises.  The log file generated by the MS server only shows incoming messages (Solicits and Requests), which is equally bizarre.  Sounds like a firewall issue, right?  I disabled it on both machines with the same results.  I have to admit, I'm stumped for now.  If anybody has any ideas, please let me know.  I had hoped to rule out the FQDN-and/or-vendor-class issue by spoofing a Microsoft vendor code and sending the correct FQDN.  I think the ISC client does have this functionality, but then I can't use pfSense as the firewall, which is a deal-breaker.

I think your confusing my setup with running l2tp ipsec on pfsense? As I thought I clearly stated this is not have anything to do with pfsense acting as any part of the l2tp ipsec connection, not a client not server.  The l2tp server is not setup or on or enabled at all. This is a client behind pfsense connecting to a server on the public internet outside pfsense. If I enabled, ie uncheck pfscrub then it works.. If I disable pfscrub then it hangs.  It use to work just fine with pfscrub disabled - but now it is not. It is currently working, I don't have any issues with pfscrub being enabled.

Problem seems to be with the "managed" option, if u run "unmanaged" it works every time i reconnect, just not with "managed" anyone else noticed this? /f

must have the bits set wrong, I'll look into it.

Same error with the new build. If I edit the restore file with 2 ipv6 dns server, both are configured in pfsense after the restore. But Package and Update management doesn't work. Unable to communicate with www.pfsense.com. Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity. DNS Lookup with the both IPv6 DNS Server works fine. Diagnostic -> DNS Lookup pfsense.com = 69.64.6.21 2a01:4f8:120:5121:6::53 6 msec 2001:4d88:1ffc:409:1::53 8 msec Any Idears ? Thx Greetings