you have to disable hardware checksum offloading. That, as he noted, is the work around.

Well, just don't stop after creating the pool, like I did.

After I created the pool I checked the status and it showed the IPv6 pool members as offline. That's the point where I posted my "problem". Because I can't let it rest I kept tinkering with it and some time later I also created the Virtual Server. After that the pool members show as online.

Apparently, after applying changed settings there is a brief moment where none of the pools are online. During testing I changed settings quicker than that reload time. I need to be more patient.

The only thing left (and which I have not "played with yet) is that when all pool members are down the incoming connections are routed to the pfSense server itself!! Which means visitors of the website are getting the pfSense interface. DNS rebinding check prevents them from being able to (try to) log in but the warning message has resulted in some posts in my forum from people who think my site had been hijacked. To prevent this I've put the pfSense interface on a non-standard port. Now when all pool members are down the site just doesn't load.

ah ok, yeah in that case your logs are gone. It's possible that check_reload_status and its monitoring process were killed off when you ran out of RAM, which would prevent the rules from reloading.

2.1-BETA1  (amd64)
built on Fri May 17 16:45:40 EDT 2013
FreeBSD 8.3-RELEASE-p8

I am running latest snapshot and can confirm the problem now appears fixed.

System log - WAN cable disconnected
–-----------------------------------
May 19 03:46:13 kernel: bge0: link state changed to DOWN
May 19 03:46:15 php: : DEVD Ethernet detached event for wan
May 19 03:46:16 kernel: arpresolve: can't allocate llinfo for 192.168.1.1
May 19 03:46:17 kernel: arpresolve: can't allocate llinfo for 192.168.1.1
May 19 03:46:19 kernel: arpresolve: can't allocate llinfo for 192.168.1.1
May 19 03:46:23 kernel: arpresolve: can't allocate llinfo for 192.168.1.1
May 19 03:46:31 kernel: arpresolve: can't allocate llinfo for 192.168.1.1
May 19 03:46:33 check_reload_status: updating dyndns GW_WAN
May 19 03:46:33 check_reload_status: Restarting ipsec tunnels
May 19 03:46:33 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 19 03:46:33 check_reload_status: Reloading filter
May 19 03:46:34 kernel: arpresolve: can't allocate llinfo for 192.168.1.1

System log - WAN cable restored

May 19 03:48:06 check_reload_status: Linkup starting bge0
May 19 03:48:06 kernel: bge0: link state changed to UP
May 19 03:48:08 php: : DEVD Ethernet attached event for wan
May 19 03:48:08 php: : HOTPLUG: Configuring interface wan
May 19 03:48:08 php: : ROUTING: setting default route to 192.168.1.1
May 19 03:48:08 ntpd_intres[29881]: ntp_intres.request: permission denied
May 19 03:48:12 ntpd_intres[29881]: ntp_intres.request: permission denied
May 19 03:48:12 check_reload_status: updating dyndns wan
May 19 03:48:19 check_reload_status: updating dyndns GW_WAN
May 19 03:48:19 check_reload_status: Restarting ipsec tunnels
May 19 03:48:19 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 19 03:48:19 check_reload_status: Reloading filter

This affects this particular install so little, I haven't had time to worry about it - but I still can't get traffic between interfaces at all most of the time (sometimes it works, the extra rule had nothing to do with it, it's actually rather random, and hasn't worked in weeks). I'm on the latest snapshot tonight and… nothing. Firewall to any address is fine. Any address to another interface's firewall address is fine. Any LAN interface out to the Internet is fine. But pinging a machine on another LAN interface or connecting to it in any way? Just silently blocked (it doesn't show up in the firewall logs, it just doesn't work).

I'm at a total loss for why - my rules should definitely be allowing this traffic to the best of my understanding.

Hi!

What happens if you set to 100 full duplex?
For me, this remediates the issue completley…

Thank you
I forgot to activate the Quick option (evaluation order) in the floating rules.

I found the problem there, fix is coming in the next few minutes, when you see a new version of the squidGuard package, upgrade it.

Should be fixed by this:
https://github.com/pfsense/pfsense/commit/37c922a6faff0e55db04fb66e43b76180e1c1449

OK, solved.
Reverted the Patch and disabled Phase2. Add an new Phase2 and now racoon is up again.

Thanks a lot for your support. Like psSense a lot. Switched yesterday from Endian and i'm very impressed.

Regards

Sven

Sweet! That fixed it

Before;
–----------
;; QUESTION SECTION:
;pfsense.local.lan.             IN      A

;; ANSWER SECTION:
pfsense.local.lan.      1       IN      A       192.168.1.253

;; Query time: 2 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Thu May 16 11:30:14 2013
;; MSG SIZE  rcvd: 51

After new gitsync and putting in - dnsmasq restarts and works

local-ttl=86400

In advanced

;; QUESTION SECTION:
;pfsense.local.lan.             IN      A

;; ANSWER SECTION:
pfsense.local.lan.      86400   IN      A       192.168.1.253

;; Query time: 2 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)

Try this fix:
https://github.com/pfsense/pfsense/commit/41567e0639d1e7541e2dbf249e3e569f017e984e

was working for me when on 15th, i upgraded and its dead, i didnt change anything in my config, just the upgrade

EDIT: my firefox had upgraded and i guess that was causing it, i deleted cache and tried and both show fine now

those are all by design. Jim addressed #2, #1 is because there has to be a way to differentiate what is and what isn't a WAN.

Ok everything is stable on just E1000. Definite issue with vxnet2 drivers. Seems to be logical as the drivers are made for pfSense 2.0 and not 2.1

For now I am not installing vmtools and will leave it at E1000 NICs

Now if someone can fix the 2.1 vmtools package.

If you just have LAN, WAN and the IPsec tunnel, then incoming from WAN to anywhere is already blocked (unless you have enabled something). So you want to also block traffic from LAN heading to IPsec.
On LAN, above the general "allow all on LAN", add:
a) pass rule, source any, destination IPsec address/s port 80
b) block rule, source any, destination IPsec address/s port all

Indent with tabs, not spaces.

http://devwiki.pfsense.org/DeveloperRules has a lot of style info. Could probably use some updating though, I see some issues with syntax on there, but they're minor things.

reply-to isn't added to interface groups by design. It wouldn't work right. They only work in circumstances where reply-to isn't necessary.

On upgrade from 2.0.x to 2.1, existing gateways are tagged as IPv4 automatically.