I was unable to install from the memstick installer (wouldn't even run live–lua errors and kernel panic) and CD installer (ran live, but couldn't find target device partly through install). Between my hardware and the pfsense USB tools, something is seriously rotten.

What's really odd is that I did once successfully boot (most of) this hardware from the embedded image on USB. Only two things have changed since then, and that is my CPU and my BIOS. I had to update the BIOS to accommodate a newer CPU. Since then I have reset the BIOS to default a couple times, and changed every setting imaginable one at a time, but to no avail.

If you have the old config.xml still, it would be enough to just install 2.0 fresh and then restore the configuration.

Thank for your assist answer  :)

the power be with you

not all protocols support a reject packet.  a block rule doesn't require protocol support.

Roy…

Even if I did want to match traffic coming in the WAN destined for port 3389, I might want to use a different queue.

I think the fundamental issue here is that the assumption of the wizard has changed.  It used to be that the assumption was the wizard shaped primarily for outgoing connections.  Switching the wizard to "any" really changes that assumption as it will now put incoming connections destined for the same port in the same queue.

While this is not necessarily a bad thing (though really it would help if the user had a choice in the wizard), this does fundamentally change things such that sites like mine are needing some change.

In our set-up, we have remote users from multiple sites who access a terminal server behind one router.  This terminal server is at the HQ site.  We want this traffic to be queued high with lots of real time so that people perceive the connection to be fast when it is busy with bulk traffic.  But we also have a set of sysadmins at HQ who may remotely access desktops at the remote sites for system administration purposes.  We want this traffic to be in a low priority queue.  This is also on port 3389.  The default rule that would be generated by the wizard as proposed here would result all traffic destined for 3389 ending up in the same queue.

This is not insurmountable - certainly one could then change the rules manually, but it is a change that seems to have side effects.

@cyboc:

I'm not crazy. Please go back and look at my screenshots if anyone doubts me.

You're right - you are not crazy.  I took a close look at the screenshots and you are correct.  The behaviour did change between Feb 6 and Feb 15 builds.

You will excuse for my impatience. Thanks!

The only thing i can do is offering it to you :-)  As as i said : bandwidth isn't a issue.  But i was wondering why it took about 7 to 10 mins to download the snapshot :)

You just need to make sure you have a modem that exposes a real serial port to the OS… If you're trying a "winmodem" then it probably won't work.

An external serial modem should work for sure.

I'm seeing the same behavior with my pfsense 1.2.3 install.

At this point I'm inclined to agree that it's a browser issue, but curious that both Firefox and Chrome are similarly afflicted.

@mynullvoid:

Also why some times my version says RC and sometimes it says BETA? (I am updating the changes by daily) ;)

we had RC1 tagged and ready for official release, but in testing it, found a remaining panic and switched back to B5 label. It'll be going back to RC1 now that those all look to be resolved.

Check the doc wiki, I think someone put up a site-to-site openvpn doc a couple weeks ago.

Hmmm, ok. Must be either my build or something screwy my end then. So long as it's ok for everyone else. Just thought I'd mention it in case it was something affecting all builds.

Thanks,

Cal.

Due to the builders being offline the latest snap doesn't have the final fix in it yet. One is building now that should have it though.

THX

Just remember, before you go trying to send the config off various places, that it may contain sensitive information so sending it via a cleartext protocol like smtp to an outside source would not be recommended.

There are some other suggestions on the doc wiki for various ways to push/pull it via http and scp. There are plenty of ways to do it securely, I wouldn't consider e-mail as an option.

And there is always the AutoConfigBackup package if you are a support customer.

Will get that information together this late afternoon.  Thanks for responding wollabybob!

Sorry for bother you.
I reconfigured pfsense from the menu and everything goes fine.

Did you do anything specific besides disabling and enabling DNSSec?

@clarknova:

This keeps happening, twice in the last day, and across 2 versions (BEAT 5 and the current one listed at top). On BEAT 5 it recovered with no user intervention. It's possible the CPU was maxed out at that time though, and I think I've seen graphing quit when the CPU is under load. This most recent outage occurred at a time when there should have been plenty of CPU cycles to go around.

when that happens, check for updaterrd processes, and check the system log for anything rrd-related.