Thanks Jim

Here it is!

Many thanks and congratulations to all who are involved.

pfsense2.1RELEASE.jpg
pfsense2.1RELEASE.jpg_thumb

You think most TLS cuts it?

I wouldn't trust a key or a cert of any length or strength that I hadn't hand-carried and exchanged privately.  Especially when you consider that every packet from the initial handshake forward might be stored, replayed and picked apart if you believe the hype…  And I do.

"The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher."

^^^^  You go ahead and trust that  ^^^^

Anyway - The things that I would do are appropriate for denying state-backed players.  Not necessarily something some guy trying to view porn anonymously would worry about.  I mean who really cares who is looking at what porn anyway?

I think I like a world with secrets better than without.  I don't like the chilling effect that happens when the only entity that has any privacy are the police/government but not their subjects.

http://www.youtube.com/watch?v=o66FUc61MvU  (funny...  but true)

Thanks Guys,

Yes I am in the UK with FTTC, I am currently getting around 31mb according to speedtest.net this morning.

I am going to try and keep it simple for now to get everything working. I will just use on NIC and then the AP from the switches for now. Once I have had a play about with, find what I like and feel more confident I may consider segregating it more. The issue with upnp over different subnets may cause a problem if I segregate the wireless from the LAN as I have one media player in the bedroom that uses the wireless.

The other reason is that the PC with the smallest case currently only has room for one PCI card… although I have another desktop that could be used it is quite a bit bigger and I am trying to do this project without spending money.

I would expect more from an Atom with Gigabit interfaces. Something >500Mbps.
It's not clear exactly how you had the test setup connected. If that's between two VMs connected to the same switch I would expect near Gigabit results, the traffic would not be going through the pfSense box at all.

It's very easy to overlook something and end up testing the wrong thing in these sorts of test.

Steve

Some things are available in the "/installer/" web installer code, could probably be re-used for such a thing.

One of the things I have in my notes for 2.2 is some gmirror management in the GUI (add drive, remove drive, etc, etc)

Where exactly did you see the error?

And which exact pfSense version? All 2.0.x versions (2.0, 2.0.1, 2.0.2, 2.0.3) are based on FreeBSD 8.1

It appears to be a PHP error from the Suhosin protection. It may or may not be something to worry about. For example, if you leave your GUI port wide open to the world and you get that, it may be worrisome. Otherwise, maybe not. Without more detail it's impossible to say.

216.146.35.35

216.146.36.36

I'm sure there are many many others.

I suppose you could also ping the NTP time servers by IP per country or region…

For example...  96.47.67.105

Some such servers don't like to get pinged every millisecond, so maybe like every 5 or 10 seconds.

For your purposes, 96.47.67.105 (or another reliable NTP server) is probably better than a DNS IP.

To do it properly you have to put the guests on a different interface+subnet. Then they can infect each other as much as they like, and you can control what they can access on the main LAN (or block all access to the main LAN). For that you have to have another NIC or a VLAN-capable switch (to securely use a NIC  to share 2 interfaces/VLANs).

You can do messy things with subnet masks, so that some groups of devices on the LAN don't actually talk to each other successfully. But anyone with their own device can set their own IP address/mask to get around that. So it can be a poor-mans kind-of solution that helps stop casual user devices from messing your real network. But it is never secure against people who actually intend to attack you.

Of course the other advice is don't have open writeable shares!

no one about pppoe ?!?

http://doc.pfsense.org/index.php/Blocking_websites

Thanks. Yes the Cavium chip does seem to rely on some binary blobs and such. It would be very nice to have it working under any OS. At the moment it just sits there using power.  ::) I doubt we'd have any luck from Cavium though if you don't ask you don't get as they say and we did get the ancient SDK from Safenet with almost no problems. Though if we developed a driver from it I'm not sure what the licensing terms would be.
I'm really looking for as OS I can boot headless from a CF card that has development tools included. Most OSes that will boot headless, like OpenWRT, are very cut down with good reason. Ubuntu server looks like a promising candidate with a few tweaks.

Steve

@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?