@phil.davis: When you reduce the subnet mask by 1, you cover double the addresses. But the subnets have to start on the correct sized boundary. "20" is already a multiple of 4, so it can be the start of a group of 1, 2 or 4 "class-C" subnets: 192.168.20.1/23 gives subnet 192.168.20.0-192.168.21.255 (2 of the "class-C" subnets) 192.168.20.1/22 gives subnet 192.168.20.0-192.168.23.255 (4 of the "class-C" subnets) To go bigger, the subnet will start on a multiple of 8, 16 etc: 192.168.16.1/21 gives subnet 192.168.16.0-192.168.23.255 (8 of the "class-C" subnets) 192.168.16.1/20 gives subnet 192.168.16.0-192.168.31.255 (16 of the "class-C" subnets) … When you increase the subnet mask by 1 you get only half the addresses: 192.168.20.1/25 gives subnet 192.168.20.0-192.168.21.127 (1/2 of a "class-C" subnet) ... Thanks alot phil, I realy appreciate this!

@jimp: @phil.davis: Maybe a screen could be added to the wizard that asks if you are going to use this system for remote VPN access. Then it could give some recommendations about picking a LAN address/subnet, a box to generate a "random" one, instructions about how to make your client get an address in the new subnet when the wizard applies the settings… Any bright ideas about how the system could be improved to help with initial config "design" without generating a support forum nightmare? Some more text would be about the only thing we would do there. I don't see the wizard randomly picking a subnet. We have the default the default for a reason. There is no guessing involved, you know what it is, and it's the most common default out there. You don't have to check the console or anything to see what the default is, it's always 192.168.1.1. Having the wizard change it automatically would be a POLA violation and if it randomized it on every run, someone could easily accidentally change their LAN without intending to if they re-run the wizard later to change something else (which is more common than you might think). If it were changed on first boot, then people without a console attached (e.g. new ALIX owners with no serial cable) would have no idea what their LAN IP is and would have to manually check their DHCP settings to find the firewall address (can't really rely on DNS there in 100% of cases). At some point we have to put the burden on the user to actually pick correct settings. Adding automatic randomization crosses that line into territory that would cause more ill effects than good. Too much hand-holding/nannying and too much room for error. Somehow I go with phil.davis but it shouldn't be a randomized to avoid "collision". In my place, ISP commonly used 192.168.1.1 in all their deployed modem-routers and in it really cause collision in the PC being installed is connected to the source during installation. I was a "victim" of that collision for a very long time since I though I need to connect my PC when installing pfsense and once it successfully installed, my connection is lost since my box would have been installed a default WAN of 1.1 while my source WAN is also 1.1. I can't open the Web GUI at all and all my wireless connectivity from the source (ISP) is also lost. I found that, it's better to detach or not to attach source to the PC when installing pfsense in that way all possible IP collision is avoided. Anyways, the default LAN IP can always be edited. It's just my opinion based on my experience.

Last time that happened to me, the computer would reliably fail during a prime95 test, but it was capacitor on the mobo, not ram causing the issue.

Same thing here, maybe if i reinstall the package it will be fine?

Huh? I don't have any India blacklist, already told you above. We don't even know what kind of blacklist are you after…

ASAP reply!!! P.S. Sorry, I just woke up. I'd have had my alarm clock set to earlier had I known I was that urgent.

Actually, China is sort of my EX-Expertise.  I can see where there might be some level of government interest in black-holing your pfsense sites there. Cool - Different thread one day.

There is also Bro http://www.bro.org/ And Bro is BSD licensed, which is nice.

thinking your confusing a domain name like local.lan with your Active Directory domain..  Which might also be called local.lan but not actually the same thing. Your pfsense would not ever actually join your windows AD domain, but yes they can share the same name space like pfsense.yourdomain.tld and ws2012.yourdomain.tld, and your windows ad dns could have a record for pfsense.yourdomain.tld in its dns.

It looks like there are promising ways to improve the algorithms by which TCP (on various OS implementations) handles changing its parameters (window size etc) in response to perceived network throughput/congestion. The control of all that is end-to-end in TCP - the end point systems have to do it, and they do it more or less crudely at the moment. So I don't see how it will help the routers/firewalls along the path. But yes, if you have a controlled office environment then you could implement these things (when they are actually real software available for the OSs that you have) and get your office computers doing more friendly sharing of bandwidth. If only new IPvN had a proper QoS system, and we could pay a bit extra to our ISP to be able to set QoS parameters in packets, have the ISP respect this, and have the ISP pay the internet backbone a bit of that money to also process QoS…

A few million people hold top secret clearances and many more than that have.  I'd estimate that about maybe 1% of the population knows exactly what is and isn't being done - officially.  Since a secret is something that you and one other person knows, this stuff aint no secret.

Enormous State tables, lots of Ram… So.... Your 10,000 simultaneous "perfectly legal" downloads won't crash your router and cause it to flake out right in the middle of your favourite Netflix episode.

I'm no fan of CALEA, but as I understand it, even CALEA has threshholds for required emplementation.  Specifically number of users and type of service.  I think this guy is too far below the radar to get forced into CALEA requirements, however that depends on how many people is "large wifi network for a nine building apartment complex".  Technically speaking. https://freedom-to-tinker.com/blog/felten/calea-ii-risks-of-wiretap-modifications-to-endpoints/ Another problem I have with logging, especially copious logging is that if a logging system is compromised, now the privacy of everyone included in the logs has been compromised. CALEA compliant systems have been "hijacked" by criminals to invade the privacy of people and even to commit financial crimes.

HAHAHHAHAHAHAHAHAHAHAHAHA!!

Huh? http://doc.pfsense.org/index.php/Static_Routes

No Problem Glad I was able to help.