Start a bounty.

@techatdd: @cmb: It can be disabled by unchecking "block private networks" on the WAN. 99.9+% of installs will want this, so it's on by default. Not sure if this is right, actually everybody using multiwan with pppoe needs it. That's not true unless you have private IP space on your WAN, which normally won't be the case with PPPoE of any kind. @techatdd: Btw, when mpd4 is implemented, will multiple PPPoE WAN-OPTx connections became possible?  :) It's in the works.

I have added code which will prevent this loop from occurring and log a message when it does.

Code already exists to fetch remote url's and turn them into aliases in -HEAD.  It needs to be tested a lot more then we can consider it for 1.3.

Easiest test is to run from livecd and rebench.

@rcarr: I just think that the WebGUI should be WYSIWYG as much as possible.  If NAT->Outbound lists an explicit rule for NATing outbound from the LAN subnet, but doesn't list one for the DMZ subnet, then I should expect that there is no rule in place for the DMZ subnet (which is incorrect). No, that should only be correct if you're using Advanced Outbound NAT (AON). If AON is disabled, the default behavior is that you will get NAT'ed out the WAN and any OPT interface with a gateway since those are treated as additional WAN interfaces as well. With AON disabled, which is how probably 98% of installs run, you won't see any rules on the Outbound page unless you add them yourself. Even if you do add them, they have no effect unless AON is enabled. That page isn't a display of how your outbound NAT is functioning if you aren't using AON. And there should be no NAT'ing other than what you explicitly define on the Outbound tab if AON is enabled. There is one known bug related to this right now, see ticket 1289. It looks like the problem you noted may be another bug created by the attempted fix on this ticket. http://cvstrac.pfsense.com/tktview?tn=1289,6 If you notice other discrepancies from what I described above, it's a bug that needs to have a ticket opened.

Ah. Thanks!

I think it has to do with the width definition of the hostnamefield in the header image iirc.

This is a known problem.  Nobody has stepped up to fix it. Patches accepted.

@ gbelanger : thank you  ;) in three words? clean, sober, effective besides, I can imagine your smile when I read your posts, and thats cool :D

Looks like it's the ntop rrd files.  ouch! –Bill

That should be rather easy and in fact it's working without issues (I'm using at at several sites as here in germany ISPs have the habbit to force disconnects every 24h.  >:( Configure your DynDNS at services>DynDNS. Make sure your pfSense has the real public IP at WAN and it not natted behind another router. Then follow http://faq.pfsense.org/index.php?action=artikel&cat=10&id=41&artlang=en

Unless the interface is completely ajax based but that is a different story  ;)

Blocked IP's are automatically removed.  We have logic now to recreate RRD databases when needed on recent snapshots. There should not be any reboot situations now except firmware upgrade.

It's open source so you can edit whatever you want. However those changes will most likely get lost on upgrading your system to the next version unless ou cleanly implement this as options in the webgui and submit your changes so we can include them in the official distribution (depends on developers decision though). Other option is posting a bounty for these changes.

It's a standard via miniitx board with vr nics that I put into a dual travla 1U case (actually 2 boards in the same 1U case). It's build from pieces and was not a full system that I ordered.

got same prob,… allready mentioned multiple times  :- quick solution: command -> editfile -> open_corresponding_file -> del everything with -property

got it thanks