I also had a large peak after the upgrade, but it disappeared after a couple of days.

logs are in RAM. if you don't have syslog they get overwritten as needed.

in console you can reset it

cli.gif
cli.gif_thumb

After 48 hours it suddenly works.  ???

Here you can see a 300 Mbit/s peak one hour before the chart started to display something on the WAN interface.

Well, yeah if you want to do that, that'll work. But again, it's pointless. The webGUI admin user has all kinds of abilities to execute whatever they desire with root privileges.

Version 1.3 should address this, a few months from now.

Something like what's going on in…

openvpn.xml:

<custom_php_command_before_form>...</custom_php_command_before_form>

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