@stephenw10: Tunable name should be: dev.cpu.0.cx_lowest I wouldn't worry about the firewall values unless you have a specific problem. Steve Thanks for the clarification ;D

To reset the states for one IP… pfctl -k x.x.x.x pfctl -k 0.0.0.0/0 -k x.x.x.x To reset all states pfctl -F state And to give the GUI a full reset, which is probably what you want to do anyhow… killall -9 php; killall -9 lighttpd; /etc/rc.restart_webgui

You need to be aware that traffic routed to a load balanced gateway cannot use the system routing table, it all goes to the gateway. This means that if you have any other interfaces, OPT1 say, you won't be able access it from lan. If you need to do that you need a rule to allow it above the default any rule. I'm sure there are many way to acheive external DNS blocking. I'm far from an expert myself, I await any other views.  :) Steve

i was able to get an ssh tunnel out w ssh -D 443 -f -C -q -N admin@192.168.0.50 but, "Firefox can't establish a connection to the server at 192.168.0.50." httpd is just hanging it looks like. netstat -a on the pfbox reveals that lighttpd is not actually listening to anything, its not listed at all where it should look like: tcp4       0      0 *.http                 .                    LISTEN which is the case on another pf box on the lan. kill -HUP PID for lighttpd didnt resolve it either. i will keep digging at least we know a rule or snort didn't go haywire edit fixed it, originally i had httpd bound to port 443 to enable ssl by default. i killed the pid of lighttpd and manually edited /var/etc/lighty-webConfigurator.conf and changed "server.port = 443" back to "server.port = 80" then start it back up again: /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf and now: tcp4      0      0 *.http                .                    LISTEN

Why don't you just make a VLAN for your various clients and leave all your servers on the .150?  You could create a .149 or .148 and segregate your clients into those networks.  This is safer anyway, as it adds another layer of control over what type of traffic can traverse over into your server network.  In addition, your Windows clients are probably nicely flooding that network with NetBIOS traffic if your not running a WINS server, better to segregate them to their own broadcast domain anyway.

pfSense already supports a number of Dynamic DNS providers including DynDNS so the DynDNS support could probably be fairly easily replicated to support CloudFlare. pfSense also DNS-O-matic which can issue updates to a number of different Dynamic DNS providers and their web page (http://www.dnsomatic.com) indicated they are open to support more. Why not talk with them about supporting CloudFlare Dynamic DNS?

It is a custom build of FreeBSD+extra packages. Custom kernel, lots of changes. So it's a stand-alone distribution, it is not something that is an "add-on" to FreeBSD in that kind of sense.

Should be fixed now

Hello; I had my host header set to the external IP address. Once I setup a host header for my internal lan address, the site loaded fine. So thanks for the help its all working now.

If you have those wifi APs setup just as access points you won't see them since they are layer 2 devices (like a switch). Is it possible that the restriction you are seeing is due to the wifi connection and just happens to be around the same speed as your WAN? Remember that the actual throughput across a wifi link is far slower than the claimed connection speed. Steve

Due to the system log 500 kbyte limit and there was one reboot so there is nothing in the logs anymore. The config history has nothing stored before the issue. I think it is too late for troubleshooting. Next time i will check these things asap. Thanks anyway!

@pethead: I just got the pfsense book for version 1.2.3 haven't seen anyone for 2.0? There is not yet a book for pfSense 2.0 @marcelloc: you will need to nat ports 80,443, and 21 on wan interface to dmz ip. See Section 7.2 (page 130) of pfSense book for a lengthier discussion of Port Forwards and how to create appropriate rules.

@wallabybob: @w00t: However, wouldn't it be possible to write a startupscript that put the interface in promisc mode on startup? :) Yes. However I expect it would be rather quicker for me to configure a bridge as suggested, check the interface is in promiscuous mode, reboot, check the interface is in promiscuous mode than it would be to write the script, work out how to invoke it safely, reboot, check it gets invoked correctly and not too early in the startup, check it won't get overwritten by a firmware upgrade etc.  Hence I would try the bridge idea first and have the startup script as a fall back. Also the bridge idea gets backed up with the configuration file, the startup script probably doesn't. Good point.

http://forum.pfsense.org/index.php/topic,42039.0.html thanks for that. Regarding the other points would it be best if I used a secondary machine to handle Freeradius and daloradius as the AAA interface ?

@stephenw10. SOLVED. VLAN190 Subnet…. not address. THanks.

For the client export, + will probably break it as it's handled in JS. It probably needs some extra code to escape or encode the whole thing. I thought it was already doing that, but I may have been thinking of a different field.