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

pfSense.jpg
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.

Check this: http://www.pfsense.org/index.php?option=com_content&task=view&id=43&Itemid=44

No problem dude - glad you got it sorted.  Have not seen anyone use an invalid IP in a long time ;)

Sorry, I didnt respond yet.. yes, I was able to do it.. now, I have another issue, posted here: http://forum.pfsense.org/index.php/topic,56796.0.html

Strange, I'm not sure what I did differently, but when I moved the DSL line back over to the new box to test and get a log file, PPPoE worked.  Oh well, just glad I'll finally get to enjoy all the goodies 2.0 has to offer.

Thanks