An outbound nat could simulate a proxy, that's the only way I could do this.

This way,server logging will have only firewall ip address.

A proxy could set a X-forwarder-ip and a web server(for example) is able to log clients ip.

You could edit /etc/inc/system.inc and edit the function that makes syslog.conf and have it direct those logs to somewhere else (or /dev/null)

You probably want /usr/local/www/status_rrd_graph_img.php

Thank you Steve that worked perfectly!

Thanks jimp. I will change the hard disk and check again.

Out of curiosity - how did you know that this is storage related?

Atul.

@wallabybob:

If its a private IP address then pfSense goes out to the web to get the public IP address.

That was the piece of "magic" I was trying to validate, as my searches didn't find anything that spelled it out.

Everything else, I already knew, as I've been running pfSense for quite a while now, with ZoneEdit handling the DNS for me.
@wallabybob:

If the public IP address changes more frequently than daily then it would be better if the IP address of the monitored interface changed more frequently OR if the address was polled more frequently.

I think my searches revealed that I could load the cron package, and change the frequency of the check.

The IP only changes very rarely, but on those odd occasions, waiting for a number of hours for the update could be quite frustrating.

Now all I have to check, is if either the FTP "helper" in pfSense when it has a "private" WAN IP, or the VoIp box, is smart enough to modify the passive FTP replies to use the public IP.  I know that pfSense, when it has the public IP on the WAN interface copes quite happily.

Cheers.

You can use the FreeRADIUS package for that, though generally people who are using RADIUS have central RADIUS servers.

Not unheard of with certain types of connectivity, though you generally shouldn't ever see that. It's usually indicative of some kind of network problem. Your description should eliminate the cause from anything on your network, it's something I'd bring up with the ISP.

Jimp thank you but I have used the prerequisites script prior to the update and it said all is fine.
However I will try to reproduce this by using a VM, let's see if it is going to happen again.

OK, thanks very much.

I'll try bridging the router first then and see if pfSense recoonects OK after link loss.

I must say that I very much appreciate the rapid and helpful replies - what a great community this is  :)

Thanks to all for the input. It was a big help.

I see, brilliant thanks. I suppose this explains why DHCP/DNS don't need any WAN rules either.

This PFSense box has been a lot to get my head around but I'm slowly getting there. :)

Thanks.

Turn your back for a second and BAM the thread goes up to 4 pages!

Why all manufacturers can't agree on a standard naming scheme for VLANs is beyond me. Cisco in particular seem to have their own names for everything.

The labeling of ports as Tagged, Untagged or Excluded is confusing. It is basically describing what action the switch will take to traffic leaving that port.

The section of network between the firewall and the switch that carries all the vlan tagged traffic from several vlans is known as a vlan trunk. Though I think that could be Cisco's naming it's pretty much universal!

Traffic within the switch, on a particular VLAN, destined for the firewall must exit onto the trunk connection and remain tagged. Hence that port is labeled Tagged.

Traffic within the switch, on a particular VLAN, destined for a client computer must exit from one of the ports with clients connected and have vlan tagging removed. Hence those ports are labeled Untagged.

All the ports which are neither a trunk connection nor an exit port for that particular vlan are labeled Excluded.

I hope that makes some sort of sense to you.

If your goal here was to get some VLAN experience then I think you're right on target!  ;)

Steve

/31 prefixes are not supported by FreeBSD in 8.x, so pfSense can't support them either.

Support was just added to 9.x two months ago, so perhaps once pfSense 2.1 moves to FreeBSD 9.x it can be added.

http://svnweb.freebsd.org/base?view=revision&revision=226572

Because of Steam Client's inconsistency at connecting to it's servers, I had took a long time tracking down the culprit.

Until one of the computers on the LAN went offline. It was apperently running utorrent.
Even though it wasn't using bandwidth heavily, it might somehow intefrere with Steam's ability to connect.

I'm not entirely sure yet, even though I was able to connect to Steam 2 times now after that PC with utorrent went down.
I'll post back after I further succeed at connecting on Steam.

Dual WAN on a Celeron 700 with 256MiB RAM. I ran a few speedtests with both WANs (30Mbs+15Mbs), then just 30Mbs, and finally 15Mbs. First peak (~100%) is @ 45Mbs, next 3 (~40%) is single WAN @ 30Mbs, next 100% peak is the pfsense control panel rendering  ;) final peaks at 20-30% cpu is with 15Mbs WAN only.

cpu.png
cpu.png_thumb