I tracked down the real issue.  What happened was some device on a different LAN port after being power cycled grabbed the firewall IP address.  After removing the switch from comcast gateway the firewall was able to reclaim its IP and comcast gateway resumed sending data to pfsense.  It looks like what likely happened is when pfsense got its IP back the ARP on comcast gateway did not update with the data that the VIP's also needed their information updated and all data was sent to the no longer existing MAC address.  Power cycling the gateway for 1 minute cleared its tables and allowed data to the VIP's to continue.

Disabling NAT reflection prevents users inside the firewall from accessing ports on the WAN interface.

Count the number of forwards you're doing, especially including port ranges. Make sure the total is less than 500. That was my problem (RTP port range for Jabber = 10,000 forwards, all set for "System Default" reflection). It's rock-solid now.

Here is one HUGE, guaranteed cause of random NAT reflection failures: Add RTP NAT forwarding for Jabber while the System Default is set to use reflection. That will do it. (For those not familiar, RTP uses UDP ports in a vast range e.g., 10000-20000 – far too many for pfSense to manage reflection) Perhaps it's a bad idea to have system-wide reflection? I'm not a novice (I'd like to think). I know that reflection can't be used for more than around 500 ports, and still I made this mistake. I may be an idiot, but I'm not new at it. I just fixed my random reflection failure by disabling reflection for my RTP forwards.

Thanks for your suggested solution but it is not an option for this case because I need to figure it out for similar scenarios from customers.

@Gloom: Exchange 2003 or 2010? Two different beasts and need a slightly different approach. Also is it only the OWA you are trying to access or are you trying to run the outlook client in RPC over HTTP mode. Just to use the EWS API with our own software. Solution: place exchange IP in squid proxy "bypass proxy for this IP"  box. For some reason "Bypass all private IP"  option has no effect.

So you mean on pfsense you had a scope of say 192.168.1.100-200 and the APs had static IPs of say 192.168.1.150? So some dhcp client would come on get an IP of 192.168.1.150 from pfsense? So this could cause issue with pinging the AP ip or accessing its gui interface over http.  But it should of had little to do with other clients connecting to the network in general or even using the AP.  Unless these AP were not actual AP and were say natting, Some other client should of been able to use the wireless or wired network just fine The only point of the AP ip in actual AP use would be to access the AP directly for config, it has nothing to do with connectivity in general to the network. When you say AP, that normally means a device that bridges traffic from wired network to the wireless.  Its IP is not even used in this conversation between a wireless client and wired network.

at the end it was that simple, lol http://forum.pfsense.org/index.php/topic,56328.0.html

No, there isn't an option to do that in an easy way from the console. You could hand-edit the config and issue a filter reload manually but there is a lot to go wrong there so I would not recommend it.

I was able to get it to work.  I purchased another DSL router (D-link).  I did not set it up it using bridge, however, I am using the double port forwarding.  It is working well and I really appreciate everyone's input and help.  Thanks and blessings, Steve

ok. but what about redirects http to https? i have some local services. they uses 80 port and clean http but outside local network i wish to use them with https. before i was using TMG, but it is soooo sloooow, so i decided to move to pfsense. and this is only one question that i didn't find the answer :(

Hi Gloom, :) Thanks I guess the problem was that I was mixed up with the fields and that 'localhost' would not be accepted at the 127.0.0.1 address. Now it works: If: LAN Proto: TCP Scr. addr/Ports: * / * Dest Addr/Ports: 192.168.1.1/3493 NAT IP/Ports: 127.0.0.1/3493 Maybe the nut settings page should describe this a bit better. Thanks all, Alfredo.

The firewall rules are evaluated from top to bottom until one matches. So make sure that this rule is placed above any other possible matches.

My webserver uses a low-powered atom processor and has about 99% down time. I keep it off most of the time. I just use it for testing purposes.

@Gloom: Split DNS gives you direct wire speed access to your internal servers (I'm guessing your internal network is running a minimum 100 Mb links but your WAN connection is 10Mb). Makes trouble shooting connections much easier and causes less load on the firewall(s) Reflection is fine for home use or small offices but is not really a goer for anything over a dozen users. I you have an internal DNS server it's just a case of altering your IP from the WAN address to the internal addresses. I've no idea how you've got your external DNS setup but all you need to do is give all of them the external WAN IP which is what I assume you have now and let the different port based NATs sort out which server gets it. Ah ok, I understand. This is only for a small home setup so I guess I'd be better off to just enable NAT reflection. Thanks!

@Gloom: If it's a fixed public IP then just put the NAT on the public interface and add a rule to allow the traffic through to the internal IP. It's exactly the same as the ones you have already setup just on a different interface. Ok, I'll try that. Thanks :)

Try to keep it simple by breaking down into small steps: Can you ping / trace from pfs to WAn and beyond? If tou can then that side is ok. Can you access outside by IP but not name? If so then DNS issue Need to show routing and firewall rules for LAN / WAN to find out more details

ok but if you going to forward 443 you will need to apply a cert to it. Either Self signed or a legit one.