You might but I have no idea where to tell you to look next.  Grep WANGW in /tmp/rules.debug and see if it's somewhere it shouldn't be.  Take a good, long look at what's really happening next time it blows up.  At least get a copy of Diagnostics > Routes.

@cmb: The TTL is just indicative of how many hops it takes to reach the destination. Which is up to your ISP generally, though if you have really screwy internal routing with multiple routers, that could be attributable to your internal network. Do you recognize any of those 10.x.x.x IPs in hops 2-10 there? The latency is high enough that they'd almost have to be on your ISP's network. And probably in two different locations judging by the latency difference (hops 2-4 close to you, 5-10 maybe 200-400 miles away). Something different with the WAN as it's configured on pfSense is being treated much differently by your ISP, and being routed an unusual-looking path. ISP routers shouldn't reply from private IP sources. Some will, with public IPs becoming more scarce, but only for a hop or two generally. I've never seen an ISP with private IPs across 10 consecutive hops. That traceroute shows higher latency getting to a real Internet router than you're describing to reach Google plugged directly into the modem. CMB, I now do feel rather stupid….LOL .. So looking at this, when my desktop "pings google" it's pinging a ISP server apparently, thus showing average latency being 10-15ms  where real google server resides at the 216.58.217.206 IP. Ping 74.125.224.72 resulted in the same latency as the pfSense box and TTL. I guess, at this point, I need to figure out why the network seemed to be "much slower" than it does when not going through pfSense, and why it keeps dropping out when connected as well. Thanks again!  :)

Also fixed IPv6 individual state killing, which had never worked at all, while I was there. https://redmine.pfsense.org/issues/4906

@n3by: if you use traffic limiter then it will break NAT … it is bug and not sure when will be fixed. And when you say the limiter breaks NAT… Do you mean just the limiter or all traffic shaping?

Have you either disabled the Windows firewall on each client or allowed them to ping each other?  If they're both on the same LAN segment, pfSense doesn't even come into the picture.

ah I see, I'll try. :) Hoping this may help other users. Thanks!

You are probably telling LAN to send traffic to your VLAN out your Multi-WAN group. https://doc.pfsense.org/index.php/What_is_policy_routing https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

You need to define a gateway group and set the gateway for your default pass any rule on LAN to the group. https://doc.pfsense.org/index.php/Multi-WAN

Thanks for everyones help.  Much appreciated.

Sadly have had to revert to our Endian Firewall. If anyone has any ideas to solve the non completion of print jobs (I've changed MTU, MSS, altered IP Fast Forwarding Settings). It would be appreciated.

Dear all; can any one help me how to config and used transparent proxy with load balancing 2 wan :-[ thanks

I would suggest you focus on getting your wireless client working on WAN first, figure out how it works then tackle OPT as you will need to set firewall rules for OPTx usage. With WAN port rules are already set…So stick ATH0 on WAN and get it going then add wired connection for multiwan. Many ways to do it so just my .02 cents. You using end to end yagi's?

How is the gateway monitoring set up?

Yes, same for option 2. No access to internet. I set up the 10.99 to test and see if there was something weird with how I did 10.90. Here is the weird thing. 192.168 worked all day. Then just as I was giving up and going home I decided to clean up my mess of wires and organize. In order to do this I had to unplug the pfsense. When I plugged it back in I can no longer get to the internet on 192.168. I had to go back to limping on my half broken ubiquity router. I'm thinking about going in tomorrow and starting over with a hard reset and setting it up again from scratch. I'm at a loss. Thanks

Not sure I follow what you're saying but the documentation is saying: Put policy route negation rules at the TOP of the list, these will have local/vpn destinations and NO gateway set. These are not "general" or "non-specific", they are there to ensure your local/VPN traffic does not exit a WAN. Put catchall/general rules at the bottom with a gateway (group) set so traffic can failover or do load balancing.

Thanks for the reply Derelict, I verified the ARP and no entry for .180 existed.  But there was one for .225 I figured I would try adding a rule any from WAN net to any to make sure my pings would get through and then everything fell into place.  :) I had just changed FW2 so its MAC was different, I'm thinking maybe a stale entry on FW1 for the Virtual IP was the issue, and once a ping finally made it, everything got updated. I since removed the any rule I just made and now they can communicate fine. I should also mention fw1 is running 2.1.2 and hasn't been rebooted for 500+ days.  :)  I have it scheduled to be updated at the end of the month, but was hoping to wait for 2.3 and go strait to it… Anyway, thanks again for the point in the right direction...