Yeah, I expect it had to do with TRIM support (not sure if TRIM is yet supported in the FreeBSD version being used), but with a large enough SSD to have spare/slack space this would likely be less of an issue. And the point about a reliable manufacturer/brand/model is very good. This isn't something that NEEDS the high speeds an SSD can provide but it does need the reliability potential.

So I just wanted to post an update about this. I know mjimlay from another forum and am the one who recommended pfSense to him. He engaged me to help him get this setup and wow was this a PITA. Long story short, I left the "142" address on ESXi so I could maintain remote connectivity to the host and attempted to use the "192" address on pfSense as he did. I could sometimes get it to save the gateway if I added the gateway in the interface setup (but could never get it to save if I added the gateway in the gateways page). This gateway would briefly show as online then go offline, probably due to come check in the background. I would have preferred to have the "142" address on pfSesne WAN and use the "192s" as VIPs (which I think is their intention) but I couldn't maintain connectivity to the host doing this. I then got the bright idea to alter the subnet mask. One of the OVH docs I read mentioned I could set the gateway to /24 instead of /32 and it would still work. I figured if that works, let's see what mask I need to use to make the "142" gateway be in the same subnet as the "192" address I'm configuring. The only valid mask for that is /1 so I tried it and surprisingly it worked. The gateway stays online and hosts behind pfSense have connectivity. This may not be the correct way to have handled this but it worked.

@jimp: I'd be seriously suspicious of the hard drive in that case. Not an intrusion. In that case…does pfSense have any SMART tools? EDIT: Never mind, found Diagnostics>SMART. It says everything is hunky dory. Hmm, guess I need to run a surface test. That'll only take a few days... Would it be feasible to just boot off a USB stick? Would I need to worry about wearing out the memory? EDIT2: Running a long offline test now. Also, since I got the GUI back up, got notice of a kernel panic from a couple of days ago. Not sure if it's related to the disk corruption or not.

I would say little to no difference.  In some theories the larger images might help with wear leveling, if that's even a feature of the firmware of the CF card, but at the same time it's highly possible that if the card did have wear leveling it'd still work even with a smaller partition.  Again, at the same time, it's not like the Nano versions are writing to the cards much. Some info/discussion here: http://forum.pfsense.org/index.php/topic,55760.msg298016.html#msg298016 If someone has more/better/deeper info, I'd be interested as well.  I'm building a new box and I'm debating "things". (I have a bunch of IDE to CF adapters, but only 256MB CF cards, so I'd have to buy new, or I've got a few physically small 1GB and 2GB USB sticks sitting around, or…)

Removing Ipguard-dev components… Tabs items... done. Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. Beginning package installation for Ipguard-dev... Downloading package configuration file... done. Saving updated package information... done. Downloading Ipguard-dev and its dependencies... Checking for package installation... Loading package configuration... done. Configuring package components... Additional files... done. Loading package instructions... Custom commands... Executing custom_php_resync_config_command()...done. Custom commands... Executing custom_php_resync_config_command()...done. Menu items... done. Integrated Tab items... done. Services... done. Writing configuration... done. Package reinstalled.

Just Installed pfsense 2.0.2 without a hitch. I think next time I will go with an i7 setup. Thank you guys for the help.

Alrighty. I will leave it for a bit.  :)

You can use any combination of load balancing, failover and policy based routing to acheive what you need. So, yes, you can send a particular protocol or departments traffic via a specific modem or group of modems. You should investigate whether or not your ISP supports ML-PPP. If it does use that instead. http://doc.pfsense.org/index.php/Multi-Link_PPP_%28MP/MLPPP%29 Perhaps you meant that instead of LAGG. Steve

Sounds like you accidentally upgraded that to a 2.1 snapshot then went down to 2.0.2. There is no way you could have gotten a 2009* php dir from a 2.0.x image.

@matguy: @jimp: AFAIK, older versions of m0n0wall might actually import more accurately than newer ones. I haven't tried it in a while, but you should really just be able to restore a m0n0wall config.xml directly into pfSense without any adjustments. Oooh, I'll try Well, I think it worked, all too well.  I was working on it remotely (RDP to a Windows host inside the network), had the interfaces islanded in VMWare on vSwitches with no live external network.  Upon booting I saw a time process taking a while, so I figured I'd give the WAN port network on my LAN so that it might hit a time server, I swapped it over to my regular LAN.  This was all well and good, it got an IP via its local DHCP client.  I imported the XML backup from m0n0wall and it asked about an interface mismatch and asked me to re-assign them since my m0n0wall had an OPT interface (not that it was doing anything) and my VM version only had LAN and WAN.  I checked the console and WAN on the top on EM1 and LAN on the bottom on EM0.  I matched that up to the web interface and clicked save.  Then I lost RDP, looking back, they were in a different order, LAN was on top on the web interface, so I just put the LAN interface live on my LAN and since the import seemed to work perfectly, it has the same Gateway address as my physical m0n0wall router. I can ping the m0n0wall router's external interface fine, but I can't get to anything inside and I don't put the web login on WAN.  I'll have to check on it when I get home, but considering what happened, I think it probably worked.

matguy - thanks for the suggestion.  Have now looked at m0n0wall - if I had found it first I might have gone that way - but I am now more than convinced that pfSense is the way to go - even if I have to scale-up hardware a little. For now it seems to be very happy - as long as I don't hit the php too hard. extide - nice suggestion but difficult with only two slots :)  Seems in any case to be running smoothly with 128MB for now. Hopefully even better with 256MB when I get replacement.  That will probably last for a while - until I can get the higher spec hardware sorted. Thanks again for suggestions / help What a great product - and an even greater community!!

see if this works [image: pfSense.jpg] [image: pfSense.jpg_thumb]

Let's not continue with this fork and follow up here instead: http://forum.pfsense.org/index.php/topic,57020.0.html Cheers Uwe

I used the Invoke Upgrade option in the WebGUI to upgrade my 2.0.1 32bit-i386 installation and it was the fastest and easiest upgrade I've ever done to one of my machines. The only thing I noticed was that I had to check the box to enable the pfBlocker package, the only package I'm using. The package didn't need to be reinstalled, just the box to enable it checked, and it kept all the CIDR lists I had set up.

You can attach pictures to the forum directly at the bottom of each post labeled 'additional options'. The setup in the picture you have posted to facebook is never going to work very well, if at all! You could use the settings I suggested in my previous post OK. The pfSense WAN address needs to be in the same subnet as the internal interface of the sagem modem device. So it needs to be either set to dhcp or set static as 192.168.0.X/24 (192.168.0.100 for example). The pfSense LAN address needs to be in a different subnet than 192.168.0.X. So you could use 192.168.10.1/24 for example. Steve

It is a mandatory step. If the system detects that the NICs do not match, it takes you to a reassignment screen where you can select the interfaces. If you restore from the console/PFI/some other non-GUI means, it will prompt at boot time for reassignment.

FYI- on 2.0.2 or 2.1, from the shell, just run: pfSsh.php playback disablereferercheck Or from the PHP Shell you can manually run: global $config; $config = parse_config(true); $config['system']['webgui']['nohttpreferercheck'] = true; echo "Disabling HTTP referer check..."; write_config("PHP shell disabled HTTP referer check"); echo "done.\n"; Less room for error that way than hand-editing the config.

In theory land, sure, VT-d might theoretically give you a lower attack surface, but in reality, it shouldn't be any more secure than a standard vNIC / vSwitch setup as long as your WAN connection doesn't also have the VMWare Service Console available on it, which it shouldn't.  In the theoretical order of attack surfaces, having a separate vSwitch with just the one pfSense firewall WAN side connected internally and a physical NIC should be the next best secure level; followed by a WAN port group and using VLAN's to separate out your WAN traffic. All of those, however, in reality land, should be perfectly secure, especially for a home. Someone correct me if I'm wrong, but I'm pretty sure that security hasn't been historically the main push for using pfSense on bare metal, but more of the performance in high bandwidth situations.  People might get the knee jerk reaction for security, or make that kind of decision based on a policy in a company, but there are relatively few, if any, attacks that would be exploitable because pfSense was running on a VM.  Now, there could be some kind of Denial Of Service attack that could possibly be exploitable, but I haven't seen any of those either. A lot of very large companies run servers on VMWare ESX hosts, some of these companies have very over-the-top security practices, and they're fine with VMWare. Unless you're worried about actually saturating a Gb NIC with traffic, I would not put out the extra expense nor effort to run the WAN NIC via VT-d.  At this point, I don't think anyone could point to a real reason to claim that networking in VMWare is insecure ("real reason" equals demonstratable exploits, not FUD.) Just to re-state, though, please don't advertise your VMWare Service Console to the outside world, though.  That's not secure.