@mr_bobo: I do have a browser I only use to log on to the Web GUI to check my logs, and always log out and close the browser right after I'm done, but have on occasion opened a new window to an online tools site I use to resolve IP#'s that appear in the firewall logs while logged in. I knew there was a reason I felt uneasy when I didn't open a separate browser to check those IP#'s.  ::) You're reasonably safe with us if you stay up to date. Other web-managed products, unfortunately not so much. There are a number of commercial security-related products with serious unpatched CSRF and XSS issues. It would be safest to assume every web-managed device has CSRF and XSS issues and act accordingly, primarily use a different browser than one you use for any general Internet usage. These recommendations from 2008 still stand true today. http://blog.pfsense.org/?p=232

Immediately.

Thank's a lot :)

My credit card is poised for action.  ;) Steve

Are those four separate shellcmd tags, or is that a script being called by a single shellcmd? You might try using nohup instead of &.

That's not unusual, as anything trying to hit DNS can make it slow down. The firmware update check is one that definitely causes it. This should be improved on 2.0.3 and 2.1 due to other changes we've made in PHP, but the only way to know if it helps in your case will be to try it out.

You would need to use a managed switch that also has the same trunking and vlans configured on it on the ports you're using.

http://forum.pfsense.org/index.php/topic,57312.0.html

That's just taken me a good minute staring at the picture to spot the error. Clearly out too late last night.  ;) Steve

I decided to install ipfire on the alix board just to see what happens. I'm not seeing any issues at all running ipfire on the exact same hardware, very strange….

Use a ssh client like http://www.chiark.greenend.org.uk/~sgtatham/putty/ Or directly with the firewall infront of you with keyb and monitor…. Connect to you firewall and login, choose option 8 (Shell) Then cd /cf/conf/backup Now youre in the config back up directory, see what files are listed ls -l You should see a lots of config files named "config-xxxxxxxxxx.xml", look at the timestamp on those files, its for you to determine which file to copy based on when you fudged up the settings, if youre happy with your choice, run cp config-xxxxxxxxxx.xml ../ The above should copy the config file to /cf/conf, we'll drop down to this directory and then backup your old config just in case, then we'll move the 'working' config in place of the old config thats giving you trouble. cd .. cp config.xml config.xml.backup mv config-xxxxxxxxxx.xml config.xml You should be done, just type exit in the console, the console menu should come up, then choose option 5 (reboot) sit back and pray.

Thank you for your fast answer! Would be nice if one could edit those lists but aliases will do it for me.

@g4jc: …The problem is, I'm not sure if the Trunking issue is with pfSense or ESXi. Thanks for your reply. I would wonder, a bit, if the direct cabling isn't working with auto-uplink, or both sides are trying to negotiate uplink states (aka: auto mdi-midix) and failing.  Or, are you using a crossover cable that isn't playing nice?  Test the link without VLANs first, to make sure that the physical connection is working, then add VLANs.

Hard to say for sure, but check the console and the system logs for any errors immediately after bootup. If they are stopped, it could be because something that is starting them up is getting caught up and stopping anything after it from loading.

I'm still somewhat of a pfsense newbie, but since there is no obvious "rule" (would be nice if there was PASS, BLOCK, REJECT, MIRROR :) ), not sure if can do this.  You could "rig" it up in a pinch using a hub…... I know, far less than ideal but if it limps you along in the meantime while you figure something else out, it's worth contemplating at the least.

And you can also list all the devices which have acquired an IP address via DHCP (if you're using pfSense for DHCP) in Status: DHCP: Steve

You can't, there isn't a package to show you that kind of info. You can get things like the CPU type, speed, RAM amount, etc, but not that level of detail. You can maybe install the dmidecode FreeBSD package (check the doc wiki on how to install FreeBSD packages) and then use it at the shell to determine some of that info.