[Whoops wrong thread] What kind of load is that system under? Does SSH work? Is it fast?

@cmb: Make a list of exactly which parts are missing input validation and open a bug ticket. This would require studying of sources of both pfSense/webGUI and hostapd. ;D But my point is not just about syntax checking, rather than about a major security flaw. What if hostapd crashes while running because of a bug or another issue? What if such issue can be deliberately exploited by an unauthenticated wireless user to crash hostapd? The network would be left widely open to anyone, and you won't know of it until some friendly person receives a warning about connecting to unprotected WLAN and informs you.

Disable gateway monitoring for the gateway in System: Routing: Gateways.

@cmb: Your WAN firewall rules are way too permissive, don't allow SSH from the Internet. what I did is kept the permissions the same but changed the default SSH port, it cut down brute force attempts by 99% also this IP is breaking guiness world of records for brute force attempts and not a single DNSBL registered it yet…. http://ip-address-lookup-v4.com/ip/91.205.189.15

I'ts a php memory limit. If you know how to handle php files, you can try to edit /usr/local/www/diag_dump_states.php and increase it. As you have 4g ram, you maybe using amd64 version. the php option to increase memory limit is ini_set('memory_limit', '490M');

Thx. Problem was solved by disable hardware raid and reinstall. Simple reinstall with enabled raid not solved the problem :( When installing on raid was problem with "cpdup fails on /mnt/dev"

Thanks for this tip - I was wondering the same thing!  Is this a "bug" and if so will be be fixed for 2.1?  Just curious, thanks.

OK, so in traditional fashion, after typing something out here, I think I found my own solution… Problem 1. The unresponsive web interface for the backup turned out to be the WebConfigurator Lockout rule getting in my way. I found this by going to Status -> System Logs -> Firewall. I looked at the blocked log entry coming from my source IP to the firewall's destination IP. I click on the Red Block symbol on the left, and it tells you what rule blocked it. To solve the issue, I removed all of my allow rules from the NAT and Rules tables allowing my external IP in to this firewall, and then I rebooted the firewall under Diagnostics -> Reboot -> Yes. Once the firewall rebooted, I went into the rules table, created a new rule: Protocol: TCP Source: {MySourceIP} (I used an alias) SourcePort: Any Destination: WAN Address DestinationPort: {MyAdminPort} Gateway: Any Queue: None Schedule: None And voila, my linux server can access the firewall Admin port again. Problem 2: Login failing with wget. This turned out to be stupid simple. Linux doesn't like the apostrophes as delimiters for the POST data. It wants quotes. Rough, huh? Good luck, and hope this solves it for someone/everyone.

bump

not saying everytime - but maybe something was stuck, I don't use chrome so have not idea but guess I could load up the page with it and see if any issues. oh here is with chrome Sure seems to be updating for me - what version of chrome are you using?  Im on 16.0.912.75 m [image: chrome1.png] [image: chrome1.png_thumb] [image: chrome2.png] [image: chrome2.png_thumb]

No idea. For now I would use pftop until one with a better clue replies in here.

You can just make a new cert in the cert manager and use it, or import an external one. There isn't a way to "renew" the certificate in that way.

@namezero111111: Incidentally, I started doing the same. Want to collaborate? Take a look on how to help http://www.pfsense.org/index.php?option=com_content&task=view&id=47&Itemid=77

Oops, sorry, it's IE bug. ??? In Fx all works fine! ::)

Pfsense is incompatible with IE? Very well…. I'll try another browser. Thanks

you can create a script and place at /usr/local/etc/rc.d dir test it before and don't forget a chmod +x on file

hi, I left it running for about 15 minutes, but interestingly enough the pkg/zip/whatever other process name running which was installing the packages finished already, I checked with top. However the webgui was still not responding to http/https requests.

If there is a command that gets run from the GUI and it gets stuck, it can cause PHP to become unresponsive. You can try: killall -9 php; killall -9 lighttpd; /etc/rc.restart_webgui