You can do exactly what's shown there that on a per-rule basis with the advanced options that are available.

I've identified the issue,

we have a cat5 connection from the service provider. I had that plugged into our main switch on it's own VLAN with the WAN setting on the router. The main reason for this is the physical length of the cable that was run from the service providers plug to our computer room.

This morning I tried moving those two cables to a desktop switch that I had. I still have the DHCP resetting issue, but the speed is working at the full 100Mbit.

I'm not sure why having a switch in linw would cause a speed issue like that, and a asymmetrical issue at that.

I know our ISP is assigning the IP based on MAC, all I can think is it has something to do with that.

Any one have any comments? is this normal?

jades,

There is a lot of info on the pfSense site about this:

Hardware Sizing:
http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49

Hardware Vendors:
http://www.pfsense.org/index.php?option=com_content&task=view&id=44&Itemid=50

It depends more on throughput, the type of traffic you have, and what services you expect to run on pfSense (VPN, proxy, etc)

@jimp:

You can filter traffic on bridged interfaces, so that would work fine, but the other concerns noted by wallabybob are valid. There will be increased CPU usage with traffic between interfaces, but that would be the same regardless of them being bridged or routed. You would also need to be careful to have each of these segments on their own layer2 broadcast domain – either separate switches or separate VLANs.

Thanks to wallabybob and jimp for your posts. On the CPU usage, not an issue, we have a dual core 3 gig of ram system to do the job. This network is only 30 users so network usage should be reasonable. Mostly just telnet traffic to a set of AS/400's and web traffic. The segments will be on there own physical switches so that should be OK.

Wallabybob, I fully agree on your comments about DNS/naming verses using IP address. I have been pushing that for a wile but now hit the wall and need to make the network changes.

Is it fare to say that as long as I through enough hardware at PFSense it can scale up to fairly hi volumes? Do we have any examples that I can show the boss if needed?

Thanks guys!

Rich

Yes, surfing the web, trying to log into Spotify, etc. All tcp/ip or udp/ip activities.

I'll see if I can get a trace later today, it's my neighbor's issue.

Thanks guys!
I will give you a full report on how things went on sunday ;)

More tips is appreciated!

2.0 is still a ways off. It'll be out "when it's ready" :-)  but is likely to be by the end of the year. It's a very ambitious release. Lots of features were added.

You can install on a gmirror, yes, but the setup isn't handled properly in the installer yet. I think it appears in the installer but does not actually function at this point. There are instructions on the doc wiki for doing it by hand, and I've setup probably a dozen machines that way over time.

@cmb:

The practical implications of this in production are non-existent for virtually every user. If you get hit with a DoS attack that big it's going to more than overfill your Internet pipe (unless you have a gigabit Internet connection), at which point it doesn't matter what your firewall does, you're offline until your ISP can stop the DoS traffic from being sent across your connection. Once it gets to your firewall, it's already consumed all your bandwidth and it's too late.

This is usually true enough. In my case, it is indeed a high-bandwidth situation so the syn smackdown pfSense got in the labs are a real possibility. Don't get me wrong; the pfSense devs have done a great job, and features like XMLRPC for config-sharing in CARP clusters are simply awesome. It just seems that a combination of weak drivers in FreeBSD* and the uniprocessor nature of PF hold it back from scaling well enough for this particular situation.

* Used to be a network engineer for a company that made a layer-7 filtering bridge based on FreeBSD so yeah, I feel your pain. :)

Hi Guys,

Remember this error I stated earlier? [kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x01 Depth 122]

This is for the DELL R300 Server with LSI MPTBIOS enabled for both OS and BIOS.

Am not sure why, but the error as reported turns out to be a faulty on-board gigabit Ethernet port, bge0, which was assigned to WAN.

The error is no longer reported when WAN connected to em0, intel server pci-x ethernet card.

…in case anyone else is searching for this error, this represents one possibility.

Jits.

Possibly, I have heard of a circumstance once where way too many nc instances get launched and makes that happen. No idea what circumstance that is, i haven't personally seen it.

I'm not experienced with those packages but it seems I heard you can tweak the configurations on Squid and maybe other packages to use less memory but by default they will just keep eating up resources. Maybe a search for configurations of Squid would be helpful.

If you just want to add a rule, check out easyrule.php in 2.0 or in the Dashboard package in 1.2.3. You could probably call that remotely with the right params and do what you need.

Much thanks to those that responded… Changed the networks and of course the routing now just works.. sigh..the bridging bit should have given me a hint...
now time to play with the new setup :D
strange that even with moderate loading (50% 6meg dsl line) the CPU ...core 2 duo 2.13Gig show 56% utilization... :O guess this is either an error in reporting or a function of beta software... time to head over to the 2.0 forum

thanks again guys for the help I shall now be able to retain the small amount of hair left  :D
Piers

In an Orange vs Nectarine kind of way, Yes.  Sort of.  Maybe.  Depends on what features you want.

They both pass packets.

They both do NAT.

They both do routing.

They "taste" different.

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

In the git repo, the hw.ata.wc=0 line is still there. Somehow, that isn't staying on a live system.

It should have:

$ cat loader.conf hw.ata.atapi_dma="0" hw.ata.ata_dma="0" loader_color="YES" hw.ata.wc="0" kern.ipc.nmbclusters="0" beastie_disable="NO" vm.kmem_size="435544320" vm.kmem_size_max="535544320"

Thought I'd reply to this because there was an extra caveat I ran into that might help others with the same problem.
In my setup, my WAN interface gets its IP address via DHCP, not PPPoE.  That means that I NAT on the WAN interface, and by default NAT is round-robin.  Adding an ip alias to the WAN interface allowed me to access my DSL modem's web interface, but pfSense started to round-robin NAT on my alias and I started losing connectivity.

It is possible to tell pf to NAT only on the main address and not aliases, but pfSense (1.2.x?) does not support the option.  Hopefully there will be GUI support for this option in the future.  Until then, here's how I did it and made it permanent (steps 1 and 4 are only needed on embedded installs):

mount filesystem as read-write:  mount -w / vi /etc/inc/filter.inc
find the function filter_nat_rules_generate_if and change
$tgt = "($if)";
to
$tgt = "($if:0)";
3)save and exit vi
4)remount filesystem as read-only:  mount -r /

That changes the NAT rule from something like
nat on $wan from 192.168.1.0/24 to any -> (sis1)
to
nat on $wan from 192.168.1.0/24 to any -> (sis1:0)

It's the addition of :0 to the interface name that will tell PF to ignore aliases on the interface and NAT only on the main address.

Hopefully somebody else finds this useful.
Also, instead of setting up a port redirection on the pfSense router, I configured advanced outbound NAT in a similar way as described in this m0n0wall tutorial: Accessing a DSL or cable modem IP from inside the firewall

Seems to be working well.