LiveCD info available at http://www.pfsense.com/index.php?id=22

Well, then your and mine machine seems to be pretty different. I have 2 onboard 10/100/1000 Intelnics using the fxp driver.

@energy:

Is this nic Intel PRO/100S good enough if u put 3 of them in a pfsense box cause they are desktop adapters? same story with Intel 1000MT nics.

I havent used intel PRO's with Freebsd/pfsense… but as far as using them under windows, they were by far one of the better (if not best) cards for throughput, and not bogging down the rest of the system.

Well, that sounds acceptable for me. Ill test it out to be sure, and if anything comes of this project ill be sure to provide a link to some kind of worklog.

EDIT:

I tried it out again, by pinging 65.5KB from one computer to another. Network traffic according to windows was getting close to 25-30Mbps (Rx and Tx total)before the pings started timing out. This was between the WAN and LAN port (Tl0 and Tl1 on the compaq dual-port server NIC). Oddly enough cpu load stayed around 30-40% most of the time. Im not sure what the bottleneck is. I could still ping a normal 64-byte sized packet between the two computers with minimal latency (10-15ms during heavy ping load, as opposed to 1ms with no load).

I dont think the compaq NIC is to blame, it can easily hit 90% loads with 100+ copies of ping running in my windows computer.

Any suggestions as to what I should be looking for? I chose to use ping as stress-testing, because I couldnt get apache to work on my computer (to test throughput while copying large files), and I felt the 50-100+ copies of ping running would better simulate dozens of users/connections, rather than just one connection.

Solved! I took another laptop with a NIC built with someting else than chocolate and I have updated the driver for the broadcom card on the server!!! For those who have an HP DL360 under Windows 2K3 with catalyst switch you need to update with the patch dated on September 25th.
http://h18023.www1.hp.com/support/files/server/us/download/24865.html

Had a chance over the weekend to install 1.0.1, so I'm in a position to report back now.

My upgrade didn't start off too well - i couldn't get the the firmware upgrade process to work…  I would get about 7-8mb through the upload, and the connection would fail.  Tried from 3 1/2 different browsers and two different operating systems, all with the same results.  However, i just did a fresh install from CD, so it wasn't too much of an issue.  The users quickly pointed out what NAT rules i had forgotten.  :-)

I tested and confirmed the bug before starting: plugged in and enabled the bge interfaces, and watched as the box crashed.  After reinstalling, I set up bge1 as WAN2, and managed to pump all my traffic through it without any problems.  I'm still in the throws of configuring it, but i currently have 3 interfaces up and running, and i pumped 100mb through bge1 at ~6mb/s during testing, so I'm fairly confident that it works OK now.

I haven't really tested bge0 - as the consensus on forums seems to be that better luck is had with the 2nd interface - however i did plug it in and get a link without the box going down, so it looks promising.  No biggie for now, as we don't have a DMZ yet.  I will let you know if it works when it comes time to implement it though.  :-)

I didn't have to play with IRQs, or disabling iLO (which is good, as i use it) - though those points are worth remembering come DMZ time.

I, too, will give some more feedback once I've been able to heavily work the interface.  I can't yet say for certain that it's functioning in a fast and reliable fashion, but as my magic 8-ball would say, 'All signs point to yes'!!

Turn back on autonegotiation. Setting modes to only one end where the other end is doing autonegotiation can have some strange effects.

Ok Bill.
For the moment I have compiled the driver and I have installed it on the 1.0.1 (using loader.conf to load it at bootup). I'm using the card for pfSync only and all seems to be ok. If I have troubles I will post it there to let people know about my tests….
Will RELENG_6_2 support BMC5714 correctly ?

Many thx for you advices.

Ok I have just send a PM ;)

Well, I did some testing and my other laptop running linux seems to pick up an address from its wireless connection. I then plugged the laptop's card into my main laptop, currently running Windoze XP. Sure enough, it picked up an IP without a problem. It's obviously a problem with the windows driver for my wireless card. Now, to figure out how to

a) successfully update the embedded image (I'm getting fopen/fclose errors on startup on boot after an update, which I'm guessing is PHP trying to write to the filesystem after it's been mounted Read Only - and I can't figure out how to re-mount the filesystem as write so that I can change /etc/platform from embedded to pfSense, reboot to allow the changes to be made and then change back to embedded), or

b) Find out why after placing my CD install to CF card of 1.01 in embedded mode I'm getting lots of "disk is dirty" messages, again I'm guessing these are due to the fact that the filesystem is mounted Read Only.

And the 512Mb CF image linked to above gets stuck pretty early in the boot process.

If it works down the road it will be added back.

Nice to see people like the FX5620.

Just a quick note to let you know about the Jetway boards we now have as well:
http://linitx.com/index.php?cPath=12_138

We have just got the new J7F4 with Dual GigLan on board.

Also the J7F2 with a 10/100 NIC on board, and optional modules to add-on up to 3 10/100 or Gig NICs.

TTFN

Nick.

You can utilize commands to turn on/off/blink lights in hidden config.xml commands on bootup or on filter reload:
http://faq.pfsense.com/index.php?action=artikel&cat=10&id=38&artlang=en&highlight=hidden  ;)

like make it blink with earlyshellcommand and switch to sold with shellcommand after it's up…

Just tested this and it works (insert below your <system>tag in your downloaded config.xml and restore it again):

  <earlyshellcmd>echo 1 > /dev/led/led2</earlyshellcmd>   <shellcmd>echo 1 > /dev/led/led3</shellcmd>

This will do the following on a wrap (like a progressmeter):

light 1 turns on when system is initializing bios light 2 turns on early in the boot process light 3 tunrs on when the bootup is nearly finished

In case you have only one LED (soekris) you can try this:

  <earlyshellcmd>echo f4 > /dev/led/led1</earlyshellcmd>   <shellcmd>echo 1 > /dev/led/led1</shellcmd>

This will make the first LED blink when early in the bootup process and switch to solid when it's nearly done.</system>

You can give it a try but if things break don't say you haven't been warned. We have introduced several performance improvements that eat some ram as pfSense is targeting at bigger systems. Maybe you would be better served using m0n0wall (depending what features you need and use). m0n0 doesn't have that high requirements.

@hoba:

First you should try to get a board with the fastest available pci bus with some good nics (intel preferred). Keep in mind that all traffic has to pass pci and cpu. As you want to run snort too make sure you have enough ram in there and also a good cpu (I wouldn't go with a celeron but that's more of a "feeling" rather than experience or benchmarks). Unfortunately I don't have the possibility to bench such systems under that load though I'm interested in the results. Please post back any findings if you do tests.

Thanks, Hoba.
There was 2 hardware platforms in my firewall.
1. Celeron 400 slot 1 (m/b Abit bf6)/256Mb RAM/2Gb HDD Fujitsy/1xIntel pro/1000 desktop NIC on DMZ & 3xRealtec Nics on LAN, WAN & OPT2. Polling was used. Snort was used with almost all rulesets checked on except nearly 12 rulesets (i.e. nearly 36 rulesets), snort was set to "lowmem". Also i used ntop. There was 10 rules on WAN interface, 8th rule was used in test. In this case i have 12Mbit/s output (on traffic from DMZ to WAN).
2. Athlon 1600+/512Ram. Other hardware was the same as in 1st case. In this case i have 50-55Mbit/s output. Then i leave only 18 rulesets in snort (vs nearly 36 in 1st case), snort was set to "ac" - the result was 100Mbit/s. I think with ntop turned off it would be 120Mbit/s.
Now i am planning to upgrade my firewall and will post back my results.

I reinstalled pfsense and it works fine now.