Issue resolved, thanks Renato.

As I mentioned on the redmine ticket, leave the digest at SHA1. OpenVPN defaults to SHA1, by setting that manually to nothing, you have created a mismatch.

Try i386 build instead of AMD64. Had the issue, it went away after I switched arch. Tunables on AMD64 only gave some extra time before "beacon stuck" spam stroke again.

Upgrade code is now pushed to 2.2 and will be available on next round of snapshots.

@Renato: I pushed a fix for that, try new snapshots and let me know if you still see issues. Still no new snapshots so I Gitsync'd.  Confirmed working now, no other issues noted in regards, thank you.

Cisco radically changed the ASA from 8.2 to 8.3.  Far more fundamental changes than are expected between pfSense 2.1 and 2.2.

My test system is located behind a FritzBox. The box is configured to use a SixXS tunnel and also delegates parts of my SixXS /48 via DHCPv6. The LAN side of the FritzBox has a /64 net so the WAN side of my test pfSense get's an IP out of that net. I don't have any native IPv6 at home.

I have also a VPN Provider as Client on my pfSense 2.2 Beta. Works without any problems. Please check your Logs on the pfSense itself. Also enable the Logging for the Firewall rules on the used Interfaces. Recheck your NAT.

Does it give any more about what the error is. Line 256 looks relatively innocuous. It is processing pfBlocker alias lists that are in ordinary text form. And I assume that since you are on pfSense 2.2 you have the current latest pfBlocker 1.0.3 installed.

Yes, its unchecked. Seth

@charliem: @ermal: The 'apply' button does not function on the ipsec pre-shared keys tab.  One must go to another tab, and then hit the apply button. fixed in new snaps. No, sorry, it still the same problem.  I make a change, say adding a PSK pair and hit 'save' radio button.  Table is updated & displayed, but the 'apply' change radio button does nothing.  Going to another tab and hitting the apply button does update the files in /var/etc/ipsec.  I confirmed that this snapshot does have the fix Ermal applied here: https://redmine.pfsense.org/projects/pfsense/repository/revisions/130a84c56839b2b36bad0630b2d7f97a39df4fe4 I pushed a fix for that.

@adam65535: It looks like it is working properly now adding -U 0 to both the system.inc and ntpdate_sync_once.sh script. Great, I'm glad it works!  Since the forum where this was first discussed is closed (2.1 beta feedback, https://forum.pfsense.org/index.php?topic=62099.msg341908#msg341908), can you post a short note to redmine: https://redmine.pfsense.org/issues/3045  This is a crutch rather than a proper fix, but it should be a big clue to the devs who can do a real fix.  That's above my pay grade though :) Interestingly I don't see the -U 0 in the freebsd man page doing a google search. Dynamic interface scanning has been in ntpd for a while, since about 2006: http://bugs.ntp.org/show_bug.cgi?id=622

Good to hear that it wasn't just me :)

@charliem: This strongswan bug https://wiki.strongswan.org/issues/586 was properly rejected because it was not a strongswan issue, but rather a FreeBSD 10.0 issue. Symptoms seem to match what I'm seeing … Was or is this a valid bug?  I can't immediately find a similar patchset in FreeBSD sources, but I can't believe a bug like this would still be around. The fix is already present in FreeBSD 10 afaik. So that patch is already merged!

Cool - I'm glad its working

OK. Back to backup, disabled DNS forwarder, installed package 'Unbound', upgraded again and it works now.

Hi, Agreed - it's just that with v2.2 there are regular upgrades (and I keep forgetting to restart Darkstat … ;)). Just figured I'd try to execute a command to configure it. Thanks!

Ok, if it's normal and not a bug, I'll mark this thread as solved.  Thanks for the answers.

Good idea Harvy66, How 'bout I just spend a week writing a btree in assembly, port that to library and feed that to pfctl in C?…  :o @Harvy66: @wcrowder: Was playing with loading aliases by removing line 10,000 at a time, largest  file I can get to load on pfSense 2.2, (today's incarnation) using : pfctl -t pfB_BTLevel1 -T replace -f /var/db/aliastables/pfB_BTLevel1.txt At 149,405 addresses it worked, any more than 150,000 results in the “bad address” error. When I dropped from 150,000 to 140,000, I worked this out. At 149,405 I received this notice: 9405 addresses added so that = 149,405. Largest "Block" list usable in pfSense is approximately 150,000 IP's, anything larger will fail regardless what is set in "Firewall Maximum Table Entries" That puts a bunch of publicly available and premium lists out of service. Instead of removing 10k lines at a time, do a binary search. Remove 1/2 of all lines, see if it works, if it doesn't, remove another 1/2. If it does work, add back 1/2 of the 1/2 you removed. Rinse and repeat.