On i386 of 3 Feb just had a hard lockup. On reboot I noticed "No Core Dump" message as messages were flying past, Borat still smiling. Upgrading to today's snapshot. Wish me luck.

Ok, I'll upgrade to a newer one this weekend and try it again.

well, use old snap then … it work for some reason ... im sure dev on hard working now ... keep good job for dev

@tuxrazor: beta2 ver 5 latest update as of 2/2/2011 stopped at ng_ether attach  0xab  , mov9 %rsi ,0x8 ( %rdx) On reboot fault is still maintained even in single user mode . Got about the same a few days ago on 2.0-1/31/2011 after starting – JFF! :) -- a pppoe server on a pppoe WAN :) Recovered somehow via series of boot into "singleuser" and "usb boot" all with an attachecd pendrive with a recovery config.xml on it. Had not Inet because of crach but still remember something so just renamed last (before this "experiment") backup into config.xml and copied it on a pendrive into cf, conf, config\ and \ :)

My bad. My very, very bad. We've got two reasonably smart (or so I thought) guys over here looking at this for two days. We thought the problem was something to do with the packets not hitting the rules to get into the queues. Boy were we wrong. Like they said in the movie contact, "the simplest explanation is usually the correct one". The test file we were transferring was 50 GB of zeros made with dd and /dev/zero. It's HIGHLY compressible. Stupid dolts that we are, we had somehow forgotten that we had enabled compression on the OpenVPN tunnel (i.e. we checked the checkbox "Compress tunnel packets using the LZO algorithm"). After turning off compression (temporarily, of course) we got the expected results. That is, the file downloaded at about 675 Kbps over the VPN (same as non-VPN test). Please don't flame me for being so stupid.  :)

I reopened the ticket with a note that it isn't happening on full installs like it should.

@ermal: Try again with snapshots of tomorrow i pushed something to protect from this even if i was not able to reproduce. ahh yes .. it's running fine now .. thanx :-)

Nope, re-saved Mobile IPsec phase 1 and site-to-site phase 1 both, one is PSK+Xauth and one is PSK, no certs for IPsec in use (and Applied changes). Certificate still shows up in Cert Manager as in use by IPsec and unable to delete. I'm going to use workaround to remove as I need it removed to finish a reconfiguration of certs now.

@myself: some things that looks a bit strange and/or unlogical 1. "really low amount" != "really needed" aka "minimal _require_ments" :) I've pointed a numbers of mem loads in a startpost. And I fogot to mention that 1.2.3 had a Squid too :) And that before Squid install it worked on 64Mb :) And without swapping (I know a magic word "top") too, like a 2-B works now on 112 (not 128!). So this "128" looks spinned out of thin air like in a Rebol-3-alpha anouncement: "At least 1 MB of disk space and 10 MB of main memory. (We just had to say that.)" ;) Of course I'll continue to ignore this warning but in this case I'll miss something new if it happens :( 2. > Don't type the /28… the # of clients... address pool... server IP isn't inside... Thank You for the tips. And let me sum up: this (and a pppoe-srv too) page(s) extremely unclear from a user point of view: Dropdown with "# of clients" -- is it mystical connected with a classless netmask or not? Text "No. PPTP users [] Hint: 10 is TEN pptp clients_" – how this "10" or even "10+2" can b associated with a common net/mask terms? Specify the starting address for the client IP subnet" string has something (a word "subnet") but its hidden consequences and requirements are unclear. 3. [see my self-quote on top] This "tiny details" (like an existence of invisible "root" or that usermanager controls a webui only or anything else) should be clearly mentioned somewhere right on the "User Manager" page. And anyway "disable" should disable (or be named different) isn't it? Also if a passworded ssh so bad and horrible and a key-only ssh so inevitable – all this should b done right "from a box".

Reported here: http://forum.pfsense.org/index.php/topic,32898.0.html I know why it is needed but don't know why it keeps on logging the warning now…

So building amd64 embedded snaps with SMP but no VGA could be fairly trivial at this point? Flip the switch!

I had similar problem when I had 3 gateways. I tried to forward port on gateway 1 to station, where station was using gateway 2. So traffic was corretly going via gateway 1, but tried to come back from gateway 2. Now again I'm hitting such problem, I'm trying to forward port to machine assinged to VLAN interface (bond0:4) with subnet 192.168.4.x where LAN has subnet 192.168.0.x, this station uses 192.168.4.254 as gateway (which is IP of VLAN interface on server) and has IP 192.168.4.20, but not on pfSense. TCP gives no connection, UDP packets can reach destination, but with "Network unreachable".

"inelegant" -  nice :-D I am using firefox - but in the future I will clean the cache before downloading config files!

See http://forum.pfsense.org/index.php/topic,32148.0.html.  That thread explains that downlink is no longer shaped when using the wizard, but supposedly you can add the queue back and then it will work.  Download shaping worked perfectly for me, forcing my low priority downloads to go slow when needed, and go full speed when possible. I haven't tried to re-create the queues, because frankly for almost RC1 pfSense is getting to be more than I want to manage.  With my must used feature removed/changed, I've just moved over to untangle for now, and while it works for shaping downloads, it doesn't seem to work as nicely.

A normal alias can only handle somewhere around 3000 entries, give or take. You could stick those entries in a text file on a web server somewhere and have it load them as a URL table alias that effectively has no limit.

@Beerman: @jnorell: Just a guess, try taking "quickleave" out of your configuration. Can you explain, how? I've not used it offhand, so no (I assume there must be no config option for that, nor direct config editing page).  Maybe just ssh to the box, find the config file, edit it and restart the proxy as a test (which might well be undone the next time you reboot or save the config). @Beerman: @jnorell: No idea how to resolve your second issue, unicast->multicast transition, I'd guess it has to be sorted out in your endpoint (stb or video player).  Just curious, does it work smoothly without pfsense/igmp proxy in the mix? It worked fine with the Router from my ISP (Speedport 920V, a special Version of a Fritz!Box), so I think it´s a issue of the IGMP-Proxy of pfsense. Or it might have to do with how the firewall works, eg. ignoring/forwarding duplicate packets or the like.  You might be able to get a packet dump of such a transition that works with the speedport and another that fails with pfsense and compare them and maybe tell what's going on .. and as such the nature of what would need done to fix it.  Alternately (or additionally), try taking a capture of the packets "before" it hits pfsense and after and compare those.

UPDATE Well, I really don't know what is going on.  I changed the phone's IPSec parameters to negotiate everything possible itself, just in case.  The server is set to P1- 3DES/MD5, P2 - all/MD5.  The dh group is the same on both ends.  PFS is off on both ends.  Here's what happens through some excerpts from the IPSec debug log: Feb  2 00:22:38 gw2 racoon: ERROR: such policy does not already exist: "10.10.90.1/32[0] 192.168.43.0/24[0] proto=any dir=in" Feb  2 00:22:38 gw2 racoon: DEBUG: pk_recv: retry[0] recv() Feb  2 00:22:38 gw2 racoon: DEBUG: get pfkey X_SPDUPDATE message Feb  2 00:22:38 gw2 racoon: DEBUG: sub:0xbfbfe6a4: 192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out Feb  2 00:22:38 gw2 racoon: DEBUG: db :0x28548148: 192.168.43.0/24[0] 192.168.43.1/32[0] proto=any dir=in Feb  2 00:22:38 gw2 racoon: DEBUG: sub:0xbfbfe6a4: 192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out Feb  2 00:22:38 gw2 racoon: DEBUG: db :0x28548288: 192.168.43.1/32[0] 192.168.43.0/24[0] proto=any dir=out Feb  2 00:22:38 gw2 racoon: DEBUG: sub:0xbfbfe6a4: 192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out Feb  2 00:22:38 gw2 racoon: DEBUG: db :0x28548648: 10.10.90.1/32[0] 192.168.43.0/24[0] proto=any dir=in Feb  2 00:22:38 gw2 racoon: ERROR: such policy does not already exist: "192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out" -> Here the TFTP files download through the tunnel and the call server is contacted.  The phone apparently logs into the call server.  As soon as what appears to be the first data is sent from the phone, the tunnel is suddenly renegotiated with no error in the log: Feb  2 00:24:01 gw2 racoon: DEBUG: === Feb  2 00:24:01 gw2 racoon: DEBUG: 722 bytes message received from 70.74.185.113[6767] to 75.152.250.47[4500] Feb  2 00:24:01 gw2 racoon: DEBUG:  e9496040 d098d033 00000000 00000000 01100400 00000000 000002d2 04000194 00000001 00000001 00000188 0a01000a 03000028 01010000 80010007 800e0080 80020002 80040002 80030001 800b0001 000c0004 00069780 03000028 02010000 80010007 800e0080 80020001 80040002 80030001 800b0001 000c0004 00069780 03000024 03010000 80010005 80020002 80040002 80030001 800b0001 000c0004 00069780 03000024 04010000 80010005 80020001 80040002 80030001 800b0001 000c0004 00069780 03000024 05010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00069780 03000024 06010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00069780 03000028 07010000 80010007 800e00c0 80020002 80040002 80030001 800b0001 000c0004 00069780 03000028 08010000 80010007 800e00c0 80020001 80040002 80030001 800b0001 000c0004 00069780 03000028 09010000 80010007 800e0100 80020002 80040002 80030001 800b0001 000c0004 00069780 00000028 0a010000 80010007 800e0100 80020001 80040002 80030001 800b0001 000c0004 00069780 0a000084 0bf87a Feb  2 00:24:01 gw2 racoon: DEBUG: anonymous configuration selected for 70.74.185.113. Feb  2 00:24:01 gw2 racoon: DEBUG: Marking ports as changed Feb  2 00:24:01 gw2 racoon: DEBUG: === Feb  2 00:24:01 gw2 racoon: INFO: respond new phase 1 negotiation: 75.152.250.47[4500]<=>70.74.185.113[6767] Feb  2 00:24:01 gw2 racoon: INFO: begin Aggressive mode. … -> The second attempt also appears to be successful, but ends as follows with a pfkey_DELETE.  The tunnel is rebuilt, the phone resends its first data packet and it all falls apart again.  Every following attempt follows the same pattern: ... Feb  2 00:24:03 gw2 racoon: ERROR: such policy does not already exist: "10.10.90.1/32[0] 192.168.43.0/24[0] proto=any dir=in" Feb  2 00:24:03 gw2 racoon: DEBUG: pk_recv: retry[0] recv() Feb  2 00:24:03 gw2 racoon: DEBUG: get pfkey X_SPDUPDATE message Feb  2 00:24:03 gw2 racoon: DEBUG: sub:0xbfbfe6a4: 192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out Feb  2 00:24:03 gw2 racoon: DEBUG: db :0x28548148: 192.168.43.0/24[0] 192.168.43.1/32[0] proto=any dir=in Feb  2 00:24:03 gw2 racoon: DEBUG: sub:0xbfbfe6a4: 192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out Feb  2 00:24:03 gw2 racoon: DEBUG: db :0x28548288: 192.168.43.1/32[0] 192.168.43.0/24[0] proto=any dir=out Feb  2 00:24:03 gw2 racoon: DEBUG: sub:0xbfbfe6a4: 192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out Feb  2 00:24:03 gw2 racoon: DEBUG: db :0x28548648: 10.10.90.1/32[0] 192.168.43.0/24[0] proto=any dir=in Feb  2 00:24:03 gw2 racoon: ERROR: such policy does not already exist: "192.168.43.0/24[0] 10.10.90.1/32[0] proto=any dir=out" Feb  2 00:24:09 gw2 racoon: DEBUG: pk_recv: retry[0] recv() Feb  2 00:24:09 gw2 racoon: DEBUG: get pfkey DELETE message Feb  2 00:24:09 gw2 racoon: ERROR: pfkey DELETE received: ESP 75.152.250.47[4500]->70.74.185.113[6767] spi=1671308013(0x639e22ed) If anyone can interpret this as to why it might be happening, I'd sure appreciate it.