Yep, the problem was with WAN being detected as down. After changing the monitor IP to an outside source, WAN was detected as up and PFSense would automatically (and very quickly) switch traffic back to WAN when WAN2 went down. It looks like PFSense will try to push traffic even when it does not detect a live gateway. So when it detected both gateways down it would try pushing traffic through the higher tiered WAN2. I have solved my own problem. Though that is good it has denied me of any wisdom you guys could have given. But this won't be the last problem I will run into so until next time  ;D FYI Sprint runs some heavy NAT on all their devices. They use a wide range of IPs between your phone\modem and the internet. I found this out one day when I was trying to forward ports through my phone. The app I was using was reporting an odd IP that I did not recognize as Sprint's. A quick search online told me the IP belongs to the CIA. After a heart attack and some more digging I found that Sprint uses this range as part of their internal routing.

LAN is setup to allow everything going out, nothing in the logs at all when packets are lost. The only stuff i see on the firewall is what the packetcapture managed to snap up. I will try to upgrade pfsense to see if the problem disappears.

Just trying to find whatever you have configured wrong.  If it was configured right it would be working.  Good luck.

@safetynet: 3.  Yes if you really want to, just set a rule on your LAN interface to use a particular gateway for all your outbound traffic. But if you're not advertising a specific IP network (almost certainly you're not, or you're running BGP, have an ASN, and wouldn't be asking those questions here, etc) all the return traffic for those outbound connections will come back over the same circuit so you won't have one for upload and one for download.

Yes, we do - one IP address which is presented to both WAN1 & WAN2 interfaces by the ISP, so inbound traffic can route down either physical piece of copper.  As well as this, we also have a /29 subnet of routable IP's assigned to us (via the same bonded broadband and is subject to the same 'mirroring' as our WAN ip), which is not contiguous with our WAN ip (WAN ip ends .69, /29 goes from .249 to .253). If all I wanted to do was route the WAN ip then we'd be fine.  However, we need to NAT for inbound on some of the routable IP's, for which I need to allocate virtual IP's on the pfsense box. If pfsense isn't actually bothered about which physical interface the traffic comes in on, as long as the IP info is correct, then I guess I could just assign all the VIP's to WAN1, but I don't want to put ourselves in a position where if WAN1 fails, but WAN2 is still up, we don't get any of our inbound traffic.

Hello All, The above problem was in fact not a routing problem on pfSense system part. The Windows Server 2003 DC  gateway was set to the Adtran router gateway rather than the actual pfSense router's gateway address. I believe it may have been related to packet timestamps being way off between Adtran , and pfSense routers., ? After changing the Windows Server DC (which was supplying the wins, dns , smb) that was being blocked these blocks have disappeared from the firewall logs. For some reason,this did not occur on the previous pfSense-2.0.1 system.? Thanks

Martin, I am still investigating what is exact;ly happening with our pfSense-2.1.4-RELEASE(amd64). We are in a  similar situation as your setup,,other than our pfSense is staic routed to an ip phone and a teacher segment lan router that has wokred fine with pfSense-1.2.3 and pfSense-2.0.1 but with pfSense-2.1.4 i am seeing lots of traffic blocked in the fiewrall logs and i am very certain the lan and OPT inerface rules should be passing all traffic,,between lans. If I disable the static route temporarily,,this blocking stops (in the firewall logs)? I'm not real smart but if i spend enough time on something i can usually hammer it out. What we are suffering from is on a Windows domain dns wins smb is being blocked,,,with this scenario. Not good in a production setting. I need to get wireshark on my setup,ro see were the packets are getting confused at. I setup two other pfSense machines at two of our other school buildings at the same time,with a  much simpler setup,,and couldnt have been any easier to setup. Thanks Barry

Unfortunately，it is still in 2.1.5!

To actually answer your questions, 1. You won't need to do anything to pfSense. Create your point-to-point IPs and you're good to go. I have mine set up the same way - pfSense on 10.105.0.1 and a routed port on 10.105.0.2 on my switch. 2. Yes, as long as you've got a correct route, NAT will work fine whether or not you have an interface on the same subnet.

It was not working correctly on my machine, which is why I made this thread. If it had been, there wouldn't have been a point.

After you create the bridge you can assign it as if it were a real interface. –> You can set an IP on the bridge interface. Since the two devices on their VLAN can't talk to each other: Did you create rules on the VLAN interfaces which actually allow traffic? By default all traffic on new interfaces is dropped. You can create interface groups to apply a specific set of rules to all interfaces which are in this group. To start it might make sense to create a group containing all your VLAN interfaces and allow all traffic from all. Start limiting access after the basics work.

Managed to resolve this myself in the end. It required me to disable/delete all the Ipsec tunnels. Keep the DSL interface as the WAN interface and the Wifi interface as an additional interface. Then set the default route as the Wifi's Gateway (though I didn't actually have to set a gateway on any of the interfaces for this to work). The bit that brought it all together was having a policy based forwarding rule back at my main office that said any traffic to any of those networks on the other end, to re-direct it to the interface with the Wifi's gateway on it, with the next hop being the Wifi interface on the other end. Also needed a NAT rule on my main HQ Firewall to say that all traffic going to the outside world from those networks on the other side to be NAT'ed through an adapter with a route out (in this case an external IP configured on an interface on the main HQ firewall). Anyway, I hope that helps anyone trying to do this same thing.

Sorry, Do you already have a base rule to allow OPT1 to access anything? OPT1 ID | Proto | Source  | Port |    Destination | Port | Gateway | Queue | Schedule | Description   |  IPv4| OPT1 Net | *    |        *      |  *  |    *    | none  |          | Do you have NAT Reflection enabled? That it I tested wihit NAT Refletion  Enable (Pure Nat) and it worked Thank a lot, you are the greatest  ;)

@Derelict: Every interface should have a rule like this.  And every client machine on each segment should have its default gateway set to the appropriate pfSense interface address.  If you do that, and there's not something in firewalls on the clients, they'll be able to exchange traffic. What Derelict said. If you have a rule on each interface to allow any traffic to go anywhere it will work. This will not be a routing issue, because pfsense does not need routing entries for directly connected networks.