@Perry: Don't know if it helps…. A quick google search gave me http://lserinol.blogspot.com/2009/01/freebsd-network-tuning.html http://marc.info/?l=freebsd-net&m=122936905304215&w=2 commands systat -mbuf vmstat -z | grep -i mbuf @http://forum.pfsense.org/index.php/topic: This might be helpful: http://www.google.com/url?sa=t&ct=res&cd=5&url=http%3A%2F%2Fwww.bsdcan.org%2F2004%2Fpapers%2FNetworkBufferAllocation.pdf&ei=95ttR6jfBJfIhgKWvOU1&usg=AFQjCNE0FZjhZBOghCEY3a8icvugBtNDnQ&sig2=Byab07C9geQ-1Qric8fAxw You might add more ram to the machine if you are really worried about it. Do you use intel nic's? This is output from systat systat -mbuf /0  /1  /2  /3  /4  /5  /6  /7  /8  /9  /10     Load Average /0  /5  /10  /15  /20  /25  /30  /35  /40  /45  /50  /55  /60 And this from vmstat vmstat -z | grep -i mbuf mbuf_packet:              256,        0,  117963,    5685, 795130678,        0 mbuf:                    256,        0,  117455,    1087, 451249037,        0 mbuf_cluster:            2048,        0,  123650,      508, 136946898,        0 mbuf_jumbo_pagesize:    4096,    12800,        0,      104,    4085,        0 mbuf_jumbo_9k:          9216,    6400,        0,        0,        0,        0 mbuf_jumbo_16k:        16384,    3200,        0,        0,        0,        0 mbuf_ext_refcnt:            4,        0,        0,        0,        0,        0 Yes I have Intel em0 cards which I have used before without any trouble. My firewall's are mostly on Intel 1U servers. There is only one different thing - this server have a bridge between WAN card and DMZ on VLAN. Normally for DMZ I have separate card. I don't think that RAM is problem - there is 2 GB inside. Sasa

my test upnp-enabled units are one PS3, one PSP, ne XBOX360.. If i connect the xbox or ps3 via ethernet on vr0 (LAN), upnp works as expected, the xbox and ps3 reports successfull config. I have added the rule you mentioned, both on WAN and WLAN. If i try to add upnp on WLAN i see a message in logs saying upnp was started on LAN but no WLAN, since WLAN has no ip address (remember it's bridged to LAN ..) If i unbridge WLAN, and set it to a static IP, upnp works fine. Conclusion, upnp listens to LAN but not bridge0 (?)' So basicaly, my rules are now : On Lan: allow all proto from any source,port to any source,port On Wlan (OPT1): allow all proto from any source,port to any source, port And as you advised: On Lan: allow all proto from any source, port to 239.255.255.250/32,anyport On Wlan: allow all proto from any source,port to 239.255.255.250/32,anyport … Note, i upddated my setup to 1.2.1-rel and 1.2.2-rel, but this issue is still not fixed.

So more than likely whatever hardware is acting as the WAN is more than likely having an issue is what your saying?  I removed the WAN NIC and replaced it, going to see what happens.

Two things to consider: Look at the logs from pfSense to see what the DHCP client is logging - this may give you more information If it's happening with 2 completely different devices, it's probably nothing you can fix.  The problem lies with the ISP (the cable modem or the DHCP servers I'd guess).

The webgui runs on a port. Usually on port 80 (or 443 in case of https). You can not forward the port the webgui uses to an internal server and have the webgui on the same port at the same time.

At the very least upgrade to 1.2 release, if not to 1.2.2.  You'll get no meaningful help for a beta or release candidate.

Restore to factory defaults, run the initial configuration wizard.  The system handles initial setup for you.

Download a file with name like pfSense-1.2.3-20090129-0009.iso.gz, unzip it with winzip (or the like) to a file with a name like pfSense-1.2.3-20090129-0009.iso and use your CD burning program (Nero or the like) to burn a CD from this ISO image.

It might help to see exactly what command line you are using for scp and the error that results. Or try it exactly how I did in my prior post. I'm not doubting your ability to use the commands, I just think that some extra clarification and information will help. It works fine for me with via fish as well: fish://root@192.168.1.1/etc/inc/ Pulls up a list of files in /etc/inc, though I had to wait a few seconds for it to prompt me about accepting the key and then a few more seconds to enter the password.

Problem solved by applying patch from GIT. If someone need this patch to, I can send patched file by e-mail. TNX to cmb and perry for help. Sasa

Glad it helped  :) From /etc/passwd: root:*:0:0:Charlie &:/root:/bin/sh admin:*:0:0:Admin User:/root:/etc/rc.initial Root's shell is /bin/sh and has a .profile that calls /etc/rc.initial, but things like scp can still bypass .profile and execute another command. Admin's shell is /etc/rc.initial directly, so it is locked into running that on each login.