@Chucko: I find the "default gateway" confusing - if the firewall rules are directing traffic to the gateway group, what traffic uses the "default"? The system will route all traffic for which you haven't explicitely defined a gateway, through the default gateway. Also traffic originating from pfSense itself will use the default gateway unless another one is specified. @Chucko: Oh, so there's a manual configuration step to switch between the gateway groups? I didn't see a way to do the switchover between groups automatically. That makes a little more sense. Changing the gateway group is a manual procedure. It looks that you want to always use WAN1 unless it's down right? Let's suppose that at some point, for some reason you want to always use WAN2 instead, unless it's down. So you grab your rule, and change its gateway to the one which has WAN2 as Tier1. Or if you want to load balance, switch the rule's gateway to a gateway group that has both WANs on the same Tier.

Done! The problem wasn´t on quagga, but on the OSPF damon of a brocade switch core. Thanks!

I wonder there is no update so can this be reported as bug?

@j@svg: One more question, at what point is the gateway admitted back into the group? I'm not 100% sure, but I believe the previously-failed gateway is put back in the group/pool after it comes back up. This entry in the manual may be useful to you. Lastly, mostly unrelated but somewhat relevant, there seems to be a widely-reported bug with 2.1-RELEASE that some users (including myself) experience, where if a WAN interface loses its connection (say, if the cable comes unplugged) when the connection is restored pfSense gets stuck continually rebooting the NIC and will never re-establish the connection, until you power-cycle the whole box. So, if you're on a flaky ISP, you may want to hold off loading 2.1-RELEASE until they've addressed the issue.

Start here  ;) https://doc.pfsense.org/index.php/Main_Page https://doc.pfsense.org/index.php/How_can_I_completely_disable_NAT%3F#Disable_NAT

@doktornotor: Yes, you already identified that you have a problem with missing DNS records, so… the point is? The problem, which we solved with a PM or two, was that he accidentally entered fully qualified host names under the domains tab instead of just the domains. It wasn't a problem with DNS.

You may need to create acls for each lan ip range and associate it with tcp_outgoing_address directive. All in custom options.

I'll give that a try, thanks

After sleeping and getting a fresh perspective on it, I found the issue.  In my virtual IP, I read the subnet comment wrong and thought it was a CIDR range instead of a subnet mask.  Changing it from /32 to /29 fixed the issue.  Everything else I did was correct, with the exception of intentionally leaving out the port forwarding rules. Hopefully someone else sees this and it helps them figure out how to perform a similar setup.

I jsut wanted to let you guys know that the issue is gone. The problem was in the Cisco 2621 after all. I forgot to set the "last resort" on this router, so anything on a network that it was not familiar with, was being dropped and never actually went to the PFsense. Thank you for your help Robin

VRRP is CARP. Well almost. VRRP is the cisco implementation, CARP came a bit later and is the opensource implementation of the same functionality (redundancy). Actually CARP is a bit more since it offers encryption.

I'm too sick and tired to be messing with this. The problem was that the openvpn client was pulling 0.0.0.0/1, added route-nopull and route 0.0.0.0/2 (I know, it's a fugly hack, but it will work for this :) ) If there's a cleaner solution to this, I'd happily change.

Thanks for all. I solved with nat outbound. Many thanks for all.

Many thanks!! It works!! Thanks for all.

Thanks ab0tj, now I can order the last part needed and start muddling through the process. The best way to lean IMO! Again thanks for the conformation.

Some others have posted about this also. Perhaps the previous alias types are not getting upgraded correctly. If you have a copy of config.xml from before the upgrade, then post the routes and aliases sections. Then the issue might become traceable.

@rubic: Hi, turk182 This scenario will not work unless each of 3 ISP you are connected to has a static route to ip3 through pfSense01. Being ISP1 how could I know that ip3 given to you by ISP3 is behind WAN1 of pfSense01? Suppose I accept incoming packet from you with source ip3, where should I send answer? According to my routing table I will send it to ISP3 which will send it to your WAN3 where it will be dropped as packet comming in on wrong interface. You do not need public IP net between pfSense boxes. Using private net with double NAT is mach easier. Thank Rubic, So if it were double NAT, pfsense01 will just have one client which is pfsense02.

I hope you didn't disable reply-to on System: Advanced: Firewall and NAT. Look at your outgoing NAT rules: The source address shouldn't include the WAN addresses. I use an alias with all internal used (or all private networks) as source addresses.