The issue was resolved quite some time ago, and it was flood type protection on his router in front of the pfsense box..  It helps to read a thread before posting in it ;)

2.0-RC3 (i386) built on Mon Jul 4 16:48:37 EDT 2011
and seeing this issue, but only every other day or so. need to figure out how to gather traffic when the issue is it's a lot of traffic!

Hi,

take a look at this sticky post in the OpenVPN thread:
http://forum.pfsense.org/index.php/topic,12888.0.html

I didn't set this up before but as far as I know you need to use the "iroute" command in "Client Specific Override" for the networks behind the OpenVPN CLIENT.

–-- EDIT ----
the above wasn't correct at all. I corrected it a little bit. But please take a look at this thread. I think it explains it in detail.

problem solve  :D

rm -R /usr/local/www/packages/ipblocklist
rm /usr/local/pkg/pf/IP-Blocklist.sh

What snapshot? I'm on 'pfSense-2.0-RC3-1g-i386-20110708-2003-nanobsd.img.gz'.

Now the reason I'm on that snapshot (before you bite my head off about not being on the latest one) is that I had a lot of trouble through trying to get a Sonicwall site-to-site stable 2.0RC3 and this particular snapshot has been rock-solid stable for my customers tunnel (well I shipped him out 7 more of these today) for 3 weeks now. Having a stable tunnel for this customer is everything so I didn't want to chance it by going to a later snapshot which could have a bug or bug(s) that may directly or indirectly affect that crucial tunnel for us. I will certainly upgrade when the final version is released, however I will want to do it slowly, testing one unit for a couple of weeks before moving on to all of them.

One other thing I noticed is that when I restored that backup to another new box that needed to be setup it did NOT like it when I changed it from PPPOE to DHCP! When I restarted it after that it lost it's interface assigments, I have system rule errors notifications on the webgui, wireless settings were hosed! I basically had to reset up the wireless from scratch, restart, resolve the wireless dhcp server values, etc. I eventually got it all set and save a non-ppoe backup settings file for future installs. I verified this issue on the second box I did as it happened again. However once I restored from the backup that had WAN set to DHCP instead of PPOE, it was fine.

We are down to 16 tickets left as "new" - which means it's more important than ever for these feedback state tickets to be checked over. If something looks fixed or you can't reproduce it, drop a note on the ticket to let us know.

Hi,

I did some tests with 2.0-RC3 (amd64) built on Thu Jul 28 05:40:09 EDT 2011.

Deleting revoked certs of a CRL is working now as expected.
Allow and deny access is working as it should. I tested it several times with revoking a cert and then deleting the revocation.

Thanks jimp!

I forgot that the WAN interface is running on 100 MBit half duplex.
Could it be that the interface is blinking while coming up and the route got lost or never set?

Where can I put a sleep command for testing this?

yes, I know… it was just "small talk"... ;)

Thanks!
Michele

Should be fixed by escaping , as I did here:
https://github.com/bsdperimeter/pfsense/commit/4222087e90badb854274109fc32de422c5c25221

@ermal:

Please try a snapshot from tomorrow and check if is ok.

Just tried with the latest snapshot, and it works great !
~28.000 folders scanned by the FTP client in less than 10 minutes, no deconnection !
That's perfect, thanks a lot !

I have the same issue. The first time I submit the report it says thank you for submitting but on subsequent submissions it gives me this message:

Processing…

Uploading...

minfree only report received. Skipping. This was fixed in a recent snapshot.

Continue and delete crash report files from local disk.

It's odd that it says it was fixed in a recent snapshot when I was on the latest snapshot available at the time.

Clicking the Continue and delete… message does not remove the banner from the top of the page but like johnpoz said, after rebooting the message seems to go away.

Committed.
For the default value i leave it as it is for now.

grazman: Thanks for taking the time to respond.

Re: I am not going to debate your putting the IP's on different interfaces versus adding them as virtual ip's. You probably have your reason for doing this.
–-
Well, yes ... unfortunately that reason would politely be called "lack of understanding."  <;-}  I never thought of it as being a problem and, since it always worked, was happy in my ignorance.

I'll read up on VIPs and see what I can figure out.

If you'd like to make a suggestion, I'd also likely benefit from that.  'Though I do have a second test setup, the only way I can really test a config (i.e., using the direct-to-ISP equipment) is via a live router which, if it doesn't work, causes downtime.

The setup (I thought) was relatively simple:

we have multiple static IPs (allocated on the same subnet)

there's one static IP per domain name

automatic outbound NAT is set

all domains are (NAT) port-forwarded (http, https, smtp) to a specific IP where that IP is actually an IP alias with all aliases on one physical server

currently, the LAN is routed by each server (alias) IP to the applicable WAN/Opt interface (even 'though they all end up via the same ISP route)

Other than some other specific blocking by IPs, that's really all there is to it, currently.

I suspect your analysis of the  "can't allocate llinfo" msgs cause is correct and is at the ISP's end.  Unfortunately, our ISP (Telus) is terrible so I generally get no help from them.  Fortunately we will have an alternative available prior to the end of the year and we'll switch (we use them at another office and they're good).  Hopefully either a different configuration will eliminate the messages or they'll be innocuous.

Regardless, thanks for you help on this.

I've had to reopen this bug as this behavior has returned in recent builds.  Luckily this is a minor issue and snmp counters do return correct data.

Sorry, my bad. :'(

My ISP suddenly changed my years long DHCP IP address to a new one.

-Raylund

@jimp:

Try to reinstall it again now. There were some binary updates to the packages that didn't go quite right. Though the correct files should be up now.

Hi Jimp!
Thanks!
Did reinstall and NUT is now running!  ;D
Thanks!
Cheers Steen

You can just use

in the build.conf - it doesn't require patching these days.

(Edit: Fixed syntax)

I committed the change.  I also fixed the path to ioncube - the one that was present was wrong.