i just applyed your fix by hand and now it is working well. thanks!

For 1. Can you show some system logs?
Normally if you have choosen a gateway in a rule it will behave that way.

I was addicted to updating as much as possible..until today. Yesterdays image seems to have screwed my ath0 WLAN. The interface stays down, when enabled. Guess i'm going back to an older version.

-edit
seems like i found the problem.

-"Common wireless configuration - Settings apply to all wireless networks on ath0."
–"Standard": set to 802.11ng causes the interface to go down after a few seconds. Strange.  ::)

Same issue here, so I created a bugreport : http://redmine.pfsense.org/issues/1564

Running version : 30 May / nanoBSD / No plugin

yeah that worked with mozilla

thanks man

@cmb:

State killing is overzealous when a WAN is down it appears. Under System>Advanced, Misc, check the box under Gateway Monitoring to not kill states. Does that make it stop?

Thanks for this advice. It sounds like I was having the same (or similar) issue that kronso mentioned (two gateways in a 'balanced' gateway group), where connections were being dropped even if they were going through the WAN that stayed up.

Now running "2.0-RC2 (amd64) built on Fri May 27 14:15:10 EDT 2011", but the issue was happening even with that version, right up until that setting was changed.

Maybe a note mentioning something about this setting could be placed on the Gateway Groups page?

Put the related system log here.
Put a tcpdump trace of traffic related to carp.
a sysctl -a | grep carp output
and ifconfig output including your config.xml if possible.

The only thing to speed up a feature to be implemented is to ask support.pfsense.com.
Surely this means having to pay for it.

In the free development cycle it will come when someone has it in the agenda.

If they share the same gateway no its not possible yet.
There are many people interested on this and they are putting money on this through support.pfsense.com.
So you can contribute through there to make this happen.

One thing is clear it will not be for 2.0!

Well, that was a interesting ride, changed opt1 back to the lagg_vlan160 and it all worked.

I did, however learn heaps so its not a waste of time, aye :)

Nice temperatures indeed. Mine is at about 48 degrees Celsius though it being totally passive cooled without a single fan.

@_igor_:

that depends on whether you have quick selected, if not, then last match wins.

so does it mean that with quick option there is no "order", but when quick is not used, the order is from bottom to top?

When quick is used the rule evaluation from top to bottom stops there…that is also the default behavior for all rules (LAN/WLAN/OPT). Only w/floating rules they are also matched from TOP to BOTTOM and the LAST matching rule is used if you haven't set the quick on a rule before that one.

If your going continue to run with that network setup then it seems to me your running a router on a stick.. Ie you have devices connecting via interface X, just for the router to send traffic back out interface X to got next hop but without the vlans.

If you back to your bridged setup, then I would say you just need the correct route on your pfsense box, before you had it set to lan as interface.  But 172.25.55.253 is not on lan its on opt1.

So your route should of been

172.16.254.0/24 172.25.55.253 via opt1 or possible your br0.  I don't have a lot of exp with bridges to be honest, have not used them since late 90's ;)  Other than a wireless ones to change from wireless to wired, etc.

But when you create a bridge would you not just have 1 ip address for the br0??  Again I don't work with bridges much.  Never seen the need on router ;)  With a router you would route not bridge - and if you were going bridge you wouldn't need to route over the bridge.

I really dont know much about BSD, thank you :)

@jimp:

new snap is building now that has those commits in it, so it should be OK once it uploads later this evening.

Awesome, thanks!
This issue creeped up on me Monday's daily build.  Decided to come post about it today. Been trying new dailies all week waiting for a fix. Each time after a rule change, manually editing out the empty or erred rules in /tmp/rules.debug
and reloading the rules from the shell.

The hardware offloading is disabled by default because some NICs/drivers do not support it correctly leading to problems. You should be OK with Intel NICs though.

Steve