[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pfsense-support
Subject:    Re: [pfSense Support] Schedule firewall - Creative solution required
From:       RB <aoz.syn () gmail ! com>
Date:       2008-03-27 22:30:45
Message-ID: 4255c2570803271530q2399c6bdye816824cf6d17805 () mail ! gmail ! com
[Download RAW message or body]

> WAN ports would be deactivated at night and then reactivate in the morning. Thereby
> only allowing traffic throught the 5th wan port which is uncapped. I see pfsense
> doesn't support such a function (yet).
You must not be seeing what I'm seeing: Firewall -> Schedules.
Combine that with the 'Gateway' option for a rule, and I'd say you can
do precisely that with very little effort.

> The one option is to set each of those 4 routers individually to disconnect their own
> WAN sessions but then can I safely rely on the load balancer to take those off the RRD
RRD what?  Are you talking about the metrics page under 'Status' or
are you talking about a WAN load-balancing setup?  If the prior, I
have no idea; on the latter, there's no reason to believe slbd
wouldn't take links that fail their connectivity test out of rotation;
otherwise, it would be classified as broken software and wouldn't have
made it into the 1.2 release.

> Additionally when I reach my cap and get throttled down to a snails pace, I would like
> the load balancer to take that WAN port out of the RRD. Is it possible to configure the
> ICMP setting whereby if a ping is taking too long then it disables the interface ?  Or
> maybe to monitor total amount of Gb's uploaded and downloaded and then disconnect once
> reached the limit ?
pfSense doesn't have this sense of voume accounting on WAN links; most
applications I'm aware of are on un-metered links.  Adding it
shouldn't be too hard, but you might have to post a bounty if you're
unwilling/unable to do it yourself.  Speed also isn't part of slbd's
failure algorithm, only whether particular packets are sent or
received.  That could be abused to make it do what you want, but would
probably result in overly-sensitive failover situations.

---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscribe@pfsense.com
For additional commands, e-mail: support-help@pfsense.com

[prev in list] [next in list] [prev in thread] [next in thread]