….whoops - 3000 is nTOP

Hi !

First things first.
Check out this page: http://www.pfsense.org/
This somewhat implies that "2.0-Rc3" is abandoned.

So: upgrade  ;)

That's a fairly old version of the code, but yeah that's the part.

It actually works fine on Android which is odd because Android's browser and the iOS browser are both webkit.

Though the theme may work, the other theme does tend to handle better on small screen devices anyhow, it's really easy to miss the menus when they drop-down.

@cmb:

That has no relation to #637 but may be a separate issue, open a new ticket in redmine if you can reliably replicate that.

done, Sir! :D

-> http://redmine.pfsense.org/issues/2253

Hi,

I think that I'm near solution for my problem. As I mentioned I'm using Option Icon 225 3G modem and that is the problem. This modem need its own driver not the one compiled in pfsense (u3g). I compile correct driver (uhso) on freebsd 8.1 to get uhso.ko file, I put that file in boot/kernel and in kernel.conf I added the line uhso_load="YES". When I attach my usb card it try to use uhso driver but it get detached immediately and than reattached and load u3g driver. Can I, somehow, disable u3g driver? This is driver compiled with kernel.

Thanks,
Nikola

Ok, found the problem. Firefox was defaulting to http.  added https://externalwaipip:8443 and it works!

Didnt need the NAT rule in the end.

Really was scratching my head on this one not to worry I was just trying out HTTPS trying to get my router a little more secure so to speak.

I accidentally yea locked myself out as I said, but couldn't work out why I couldnt get in when I'd reset for some strange reason it had made 2 rules of the same exact settings for HTTP, hmm weird but oh well I will leave it be for now and when I get back home will work out why.

There is an option when I do a setting in the SSH login (remotely in my case) to reset back to HTTP and reset the password but I can't remember actually thinking back to which one includes the HTTP reset, but it did work and thank you again I mean I just deleted the first rule I had of HTTP and it let me back in weird though oh well least it's working now.

Thank you ever so much for your help,
Jeremy.

Thank you I didn't look deep enough on the firewall rule set. Coming from another FW I didn't have to set any rules to pass traffic.

I do remeber reading something to that effect.Sorry for placing a question already covered.
Thank You for your time:)

[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