I got the idea from http://technet.microsoft.com/en-us/library/cc784800(v=WS.10).aspx.  My thinking is, rather than having to reconfigure a backup if the primary fails, why not have the backup in a sort of hot-standby mode.  Right now, configured as it is, both DCs are acting as Always/Always Reliable time sources (both have AnnounceFlags set to 5).  And, being identically configured and synchronized to the same source, they should converge to being as closely synchronized with one another as they would be if one were directly synchronized to the other.  I could disable the NtpServer setting on the backup if I only wanted one time source available at a time, but leave the NtpClient enabled so it would remain in sync.  What could go wrong with this scenario if I leave it as it is?  If I disable NtpServer on the backup?  (Not rhetorical questions  ;D)

Yeah, I am questioning why I don't just bypass the pfSense box entirely and sync directly to NIST.  Still nothing in the OpenNTPD log; I don't get that.  I might have determined the IPv6 problem faster with better feedback from the server and logs.  It is keeping my DCs within 0.05 seconds of NIST, though, and it is in default mode (there is no other :)), so whatever traffic is getting sent over my WAN is (un)throttled by OpenNTPD.  I need to check that for curiosity's sake.

What do you mean by your final statement?  Something tells me this relates to my last question in the last post.  I get NTP's making clock adjustments and I get that there is a tipping point at which NTP will just resync the time (even though it may appear to "skip" briefly) instead of adjusting the clock rate for a more gradual convergence.  My question is: does the polling interval get adjusted as well?  As the clock becomes more accurate relative to the trusted source, are fewer polls necessary (and hence fewer used) in a given time span to keep it accurate?  That would seem sensible and the presence if MinPollInterval and MaxPollInterval would seem to verify that being the case, but that would mean there would be more traffic at the beginning of the synchronization process and less as it continued.  Why did my client allow over four hours to elapse before correcting an eight second discrepancy?  Did the size of the discrepancy (small by NTP's reckoning?) affect the duration of the polling interval?  The default MaxPollInterval when clients are configured manually is 1024 seconds (about 17 minutes), but it must be considerably longer when the clients are in automatic mode (or else I'm missing something).

exactly.. its only the pfsense traffic.  Where I noticed the slow down was it using my ipv6 tunnel when talking to root dns.

I want the ability to use ipv6 for dns when I am testing it, but I don't want that to be the default, etc.

I would be a nice feature to be able to choose this - when running native it might not matter for latency.. But I can tell for sure that my he tunnel is slower than ipv4

You can make a merge request on github with the change.

I did a pkg_delete -f on the curl package then removed git.

After this I reinstalled git, it installed curl, then I did a gitsync as usual.

This time around it worked after the reboot. I believe the issue was a problem with the curl package from before probably being a 32-bit one.

Try not using the first address as your static LAN address. I was having trouble until I set my LAN interface to ::10 (and adjusted the DHCP pool accordingly).

I think the first few addresses are used by the ISP.

Cheers,

Keith

I made this change and now have the desired functionality.  Actually, I changed the line following the one highlighted at https://github.com/bsdperimeter/pfsense/blob/master/etc/inc/filter.inc#L2286 because it is the one causing me problems.  Now that it's blocking and logging, I can confirm beyond a shadow of doubt that RAs are being sent down the gif tunnels too when not blocked.  Thanks for the assistance!  Now, I think I'll tinker with fixing the RAs.  :)

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.