@Starko: Sorry I never replied! The error I got was selfmade. There has never been an issue with pfsense. I worked through our backupped config.xml with Notepad++ and did an Replace all for the changed interface names (vr1 became em1 .. etc) I was so lucky that out certs had the part "vr1" in it. So literally replaced parts of our certs, no wonder they were broken. After I replaced the interface names manually, the import worked fine on the new hardware. Thanks for the follow up. Yeah be very careful doing "replace all", as cert contents commonly will match any short string you're replacing, which will of course break the cert. When I edit configs like that, I always make sure to confirm every instance of the string that's being replaced, as there are a variety of possibilities to break things like that.

that's what we are here for ;)

just in case anyone else stumbles across this here is the fix. type ? and press enter, this will give the real drive partition number. then type ufs:/dev/adxs1a where x is the number from above. boot. shell into pfsense and edit \etc\fstab and make it match what you entered.

Issue is resolved. It was user error…..Make sure your connection speed is 9600 and not the apu default.

Sorry, forgot to insert command. After setting up squid+dansguardian when i execute the following command in ssh to install samba I am getting error please see attached log file for the error. pkg_add http://e-sac.siteseguro.ws/packages/amd64/8/All/samba36-3.6.3.tbz

pfsense 2.2 is not based on freebsd 8.3 , its based on Freebsd 10.1 2.2 is in beta and might have issues … it might be better to post them in the "2.2 Snapshot Feedback and Problems" - section of the forum

Thank you very much I will try this out.

pfBlocker is what you want.

There appear to be a number of issues that can cause the 38% issue, all of them corner cases. It's hard to say what might be causing problems for you. However 2.2 is built on FreeBSD 10.1 so a lot has changed. There's a good chance that whatever is causing it will have been updated. Try a 2.2 snapshot and find out. Steve

That's strange, I had the exact opposite problem, my flash drives were failing, I installed a $20 WD blue  3.5" HDD and never looked back. Do you know for sure that your USB stick will boot on your motherboard? I only ask because I have seen several instances where I could not boot from a USB drive, trying a different USB stick with the same setup; the system would boot.

Most packages leave their settings in the config file. That way you can uninstall them and then reinstall to clean up an issue with the installation and not have to input the settings again. That can work both ways - sometimes you really want to clean out all settings and get a really fresh start at setting things up! So yes, it would be nice if package uninstall had an option to also remove all settings.

30GB will do the job, thanks all :)

I put my cable and dsl modems on blank, untagged vlans with my WAN ports.  That might enable you to go back to the realtek and hard-set the switchport to 100-Full to the cable modem. (Security issues aside (I'd rather have a dedicated outside switch), I do it so I can put a sniffer on the outside on a mirror port.)

Short answer: edit your /etc/inc/globals.inc, change the xmlrpcbaseurl from https to http. "xmlrpcbaseurl" => "http://packages.pfsense.org/", Long answer: In order to retrieve package updates for pfsense from behind an upstream web proxy, you may need to change the base URL used by the package manager.  The pfsense updater and the package manager work differently, so system updates may work fine. Your upstream proxy probably doesn't support the mechanism that the package manager's XML_RPC client is trying to use. The package manager connects to your upstream web proxy and says something like: POST https://packages.pfsense.org:443/xmlrpc.php HTTP/1.0 User-Agent: PEAR XML_RPC Host: packages.pfsense.org Content-Type: text/xml ... Most clients would usually start their request out like this: CONNECT https://packages.pfsense.org:443/xmlrpc.php HTTP/1.0 ... Many proxies choke on the type of request that the XML_RPC client uses, but disabling the HTTPS gets around it.  The xmlrpc_client checks the URL from globals.inc, and changes it from port 443/SSL to 80 in its xmlrpc_client.inc logic.

Enjoy (-;

Waiting for NTP to timeout used to be an issue if there was no WAN. I thought it had been resolved but perhaps you have a niche case. Steve

Hi. I have similar issue. Do you success to solve? Thanks

As Jon said above if you leave outbound NAT set to automatic the rules will be added automatically when you assign a new interface or change the assignments. Steve