Technically speaking they should be equivalent. Especially if you're only interested in the upstream traffic. The pfflowd package, IIRC, uses data from pf, so it's possible there could be more data on the wire than is reported by pfflowd, in which case the switch would be more accurate.

Boot messages only are in /var/log/dmesg.boot That one is actually in plain text format. No need for clog on that one. Beyond that, clog /var/log/system.log There is some console output that does not get logged anywhere, no way to capture that unless you're recording it over serial console.

I had a desktop once that did that when it had an overheat condition. I'd also lean toward hardware causes.

Use NanoBSD or the serial memstick. Assuming your system has a serial port to use for the console. If it doesn't, I'm not quite sure how that would react.

Could it be that your hardware is too slow? I am asking since another member here who has the same ISP as I have experienced slow downs in his VDSL after using a rather 'light weight' hardware configuration. I have a relatively powerful configuration (brand new stuff, Intel Celeron G1610, Intel mobo/NICS, fast WD hard disk) and I don't notice any speed losses at all.

The package version is the same but I remember that I got a ipguard.sh in rc.d when I installed the package in pfSense 2.0.2. I monitored the boot process. pfSense somehow has IPguard registred as a service (I know, as It tells me that it is going to start ipguard) but it fails to do so (most likely because it's missing some ipguard startup script). I'd rather like to understand how pfsense handles services in general, since it differs from freebsd's way (at least in the nanobsd version). That's why I posted here :)

Probably safe/harmless, since it may not use that part of the BIOS. I see that on mine too.

@wallabybob: @Hitman247m: I wish some of my downloads were as "horribly slow" as yours :-) The "sometimes" suggests to me you might be encountering congestion when you see slow downloads. @Hitman247m: I'm trying to download some very large files, and FTP is the only practical way I can do it at the moment. I have had consistently poor results (Firefox marking incomplete transfers as "finished" with no obvious indication they were incomplete) using Firefox to download multi-media files or more than about 100MB so I resorted to using wget for that sort of download because it can often resume a download from when the connection broke rather than start again. wget can download files using ftp protocol. But I don't know have enough details about your environment to know if this is a helpful remark. Ok, thanks for your help. It probably is network congestion.

This happened to me again today  :( The network simply stopped "seeing" the pfSense server. I checked the LAN connection and it was fine. Had to reboot twice and it came back to work. I should have configured a server log. Will try to update pfSense now.

All testing came back fine, thanks to the many that helped. Release is now out! http://blog.pfsense.org/?p=694

I have provided more information as to how my ISP provides internet connection. Please note that the ip address 10.40.108.x is not put in the Win 7 network configuration but in the pfSense configuration page. Hope it helps in resolving the issue. Thanks. [image: network.jpg_thumb] [image: network.jpg]

To answer OP's question - the 35Mbps limit is a known issue w/ the POS Sagemcom modems that Bell provides. There's a few work arounds that involve double NAT or (as of today) unlocking and MacGyvering a bridge mode. http://www.dslreports.com/forum/r28103988-DSL-bridge-mode-on-Sagemcom-f-st2864.

Whether or not a gateway is specified under Interfaces determines how the automatic outbound NAT functions. No gateway on the interface == not an Internet connection == no NAT will be applied.

Of course there are apps/devices that can benefit by submitting DNS query to specific server. Take a Roku device for example.  It uses the DHCP supplied DNS server (pfSense Forwarder), but also submits a www.google.com query to google TCP DNS 8.8.8.8.  Which in my case at lease provides a different set of servers that ping in at 18 ms rather than 148 ms for the ones provided by Level 3 (pfSense DNS forwarder). That's pretty wordy.  May have to read through it a couple times. There are lots of possibilities.  To each there own.

Just to close this thread up - replacing the NIC has resolved the issues.

You can still use pfSense as a transparent firewall in front of the client. You may need to add another NIC for a management interface. Depends how many public IPs you have to play with. Steve

Yea that is what I thought too, there should be one loigin and that should take care of the other line. Its VDSL FTTN (fiber to the node). Im going to go and tackle it now, worst case Ill use dual wan…

After playing around with it - I discovered that I needed to move to Manual outbound NAT - I didn't realize that when Automatic NAT is turned on that it ignores all the rules that are set. By adding some rules to allow outbound traffic on the main LAN and the OPT lan - that I can have my main LAN NAT to the interface address and then allow OPT's lan to NAT to the static IP of .131. Now I can do this with the few others that need to have it done. Thanks!

pfSense logs are circular logs. That is they are fixed size (cannot grow indefinitely) and contain only the most recent entries. You need to use the clog utility to convert them to standard text, for example:``` clog /var/log/system.log pfSense uses FreeBSD but it is not FreeBSD.

Seems to have been something obvious since it has been fixed upstream right away. The packet loss is minimal again. They didn't tell me about the cause though. Would have been nice I think. Something like "sorry for the performance issues, our foo was bar and has been replaced".