@jimp: pfSense logs are only stored in /var/log, not "all over the place". There may be some packages that break that convention but they are the exception, not the rule, and the packages should be fixed if they are doing that (where possible), or at least under /var/. A custom install allows for creating multiple partitions and such, though using a second disk isn't so simple. We have plans to revamp the installer soon, so that might show up, but it's too soon to say.  For those that need/want to use a second disk, formatting and adding it to fstab is fairly easy for the technically inclined. What I meant for "All over the Place" was in the GUI. You have to click around through some of the different functions to find the logs. My suggestion; which is still valid by the way, is to move the log directory to a secondary disc that has a catalogued files system specifically for logs and create a central location in the GUI to manage and clear ALL logs.

@maverick_slo: Lol. But my solution works you know… Tested :) Truthfully the only way I see my firewall having problems while Im out of town is a hardware failure. Since my wife nor any of our kids will probably not be trying be configuring the firewall in my absence.    ;D Your solution seems the most logical. But in any event.  jbhowlesr -  download putty and learn it while you have a chance. https://www.youtube.com/watch?v=krNuKDGEjvQ

@jdillard: @jwaz: It seems I'm not able to access anything but the latest Hangout It is most likely an issue with a browser plugin that you are running. Indeed, in this case it was EFF's Privacy Badger. Thanks j

I started a sticky thread here to get things started: https://forum.pfsense.org/index.php?topic=105184.0

Same here very difficult to browses. It would be great if Tapatalk is allowed

You trying to run 2 subnets over the same wire??  devices on subnet 2 it would be impossible to get an dhcp address from subnet 4..  Unless you think you can just run 2 different address schemes over the same wire and run 2 different dhcp servers??

Hooray!  8)

Yeah that's the bbcode for that smiley. Check the box, or put the output in a code or quote block (always best for command output), if you won't want it to do that.

lol My point was that maybe pfsense guys could do nothing about it :=) That issue was on higher level… Unheard levels...

Updated earlier, thanks.

+1 Good idea!  8)

I have thought about a similar idea of posting fairly short gifs that highlight different features of pfSense with a short description (140 chars or less…) in the hopes they get passed around the twittersphere. Maybe it is something that could also be community generated, we could post the specs of the gif (desired dimensions and length) and people could post their ideas...

There was an issue, since fixed. Your post should have gotten through. If not, go ahead and re-send it.

I see the A+ score - nice!!!  Much better than a C ;)

Ah well, obviously something munged at my end. I'll have to investigate further. Thanks for checking and confirming the Forum performance.

spoofed-DDOS (sDDOS, a new acronym?) really should be stopped at each ISP before it gets onto the internet backbone: a) Customers with public IPS: Each ISP has customers connected and knows what public IPs it has allocated to those customers. If it receives any packets from a customer with a source IP that is not one of the customer's proper allocated public IPs then drop the packet. b) Customers who are not given public IPs but are in a CGN or similar managed by the ISP and who end up on shared public IPs: The ISP can filter internally to make sure individual customer packets have source IPs that match the internal IP given to the customer. In any case the ISP will NAT this stuff out to the public internet so dodgy source IPs will (should) be NATed out to be the ISP public IP. Thus the "spoofed" and "distributed" are not effective. It becomes like an ordinary "DOS". c) In regions/countries where there are small ISPs that are [not willing|can't be trusted|do not have the technical skill] to do this filtering of traffic from their customers, then the next level up part of the backbone (to which these ISPs connect) should filter traffic, making sure that the source IP of all traffic received from "small and dodgy ISP X" is actually one of the public IPs that is allocated and routed to that ISP. If that was put in place, then end-customers could not mount spoofed DDOS attacks just from a single place. They could still do ordinary DOS from 1 or a few of their own source IPs. But that is easier to mitigate because the firewall can have pass rules that limit the number of new connections per second from each source IP and quickly start dropping the incoming SYN packets without creating state… - which should be much less processor intensive and not fill the state table. And of course if someone has a bot that that they have managed to get installed in 1 million hosts via some malware then they can mount a real DDOS, rather than sDDOS.

I have seen similar behaviour on other sites, though not here, if you have load-balanced WANs. Connections coming from alternating addresses can confuse login status. Steve