What version are you running? That looks like something that was fixed before 2.0 was released, where a missing or disabled interface (or perhaps it was rules?) were finding their way into the ruleset somehow. It could be something else, but that looks familiar. It would help to see a full copy of your /tmp/rules.debug file when this error happens.

Just want to say thank you to you all for replies!! appreciate all your help! i have only just joined this forum and im getting more and more confidable with the product. Thank you again for a wonderful product!! i have implemented these boxes now around to some of clients! im that impressed! and using it in my Datacenter! Cheers x

You'll either need proper return routing, or to use outbound NAT to translate traffic going to that host.

You definitely have a routing loop somewhere, not enough details there to tell you where.

Thanks for the explanation, I think I understand it now :) So it's still better to enable both setups.

@ptt: It is not about get 2.1, it is about get "sticky connection source tracking time out" option just as it is in 2.1 http://forum.pfsense.org/index.php/topic,43989.msg229457.html#msg229457 Ok, I misunderstood.

It's a limitation of the OS, and it's possible it may never be properly solved for these cases. We have looked at things like ECMP but there are issues with almost every method. Search around the forum, it's been discussed dozens if not hundreds of times over the years.

Bypass firewall rules for traffic on the same interface. That seems to have fixed it. thanks ;D

There are really cheap Intel MT dual nic on Ebay… (PCI-x) They work great!

Those packets are TCP FIN+ACK packets, so it's the last packet of a closing connection. Most often, it's this: http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F

I figured it out :-) Added two outbound NAT rules for the interfaces, source "any". Thanks.

@cmb: For routed subnets, you do not want VIPs (other than type Other), just have them routed to a CARP IP on your main IP block. Ok, great.

Thanks SeventhSon, but this doesn't appear to be the problem. As I said, I have even tried disabling the monitoring. I have tried several monitor IPs. And the graphs shown are with monitoring disabled, from and external network monitor.

You probably want some Manual Outbound NAT magic to get this to work properly

@eytanes: Is there any way to get the reply traffic route via a specific gateway without using the routing table. The reason I'm asking is that I would like the return traffic out of an interface to use a gateway group. I've found that the 'gateway' field in the firewall rules only apply to traffic generated on that side. Any return traffic that goes through will always use the routes in the routing table and not the rule. That's a much different scenario than this one, the reply-to is automatically added to WAN rules which takes care of that. The exception being where you have multiple routers on the same interface, then reply-to is only set for the one chosen as the gateway on that interface. Disabling reply-to is at times a work around for that. Please start a new thread with a description of what you're trying to do for further feedback.

SOLVED! The 'Gateway' field should be filled in the Interfaces->OPT1 configuration section. Then just add WAN and OPT1 interfaces in Load Balancing mode (Services menu). Thus, all incomming packets on the LAN interface also obey the defined static routes. Cheers!

SOLVED In theory only though.  I havent had time to test so correct me if im wrong. Make a firewall on the LAN interface.  Specify the source as being from the LAN subnet.  Destination being the IP and/or ports its going to.  Then at the bottom under advanced options simply choose which gateway.  Must make sure you add that 2nd WAN as a gateway.

… I read that so many times now I see the pictures.... Also it fixed my issue thank you