Moises,
I would start with watching the syslogs - preferably at the 'debug' level. The other three items to consider with Cisco (and possibly other) firewalls are:
1.) Permission
Make sure that an access-list allows the traffic and/or the implicit permit for high-to-low security traffic.
2.) Translations
Make sure that a translation is present for the traffic. If everyone is PATed to a single outside IP address, be sure that all of these translations (roughly 65k) are not consumed. You can watch the output of 'show xlate debug' at the time of the traffic to ensure that a translation is happening. You should see a source interface and IP address and a destination interface and IP address that matches. If this information doesn't make sense based on what you were expecting, you may choose to clear the xlate for that particular connection ('clear xlate...').
3.) Routes
Ensure that the routes for the relevant host is indeed pointing out the correct interface in the direction of the server.
After you confirm #1-3 above, the other things to check would be the status of the connection and/or connection syslogs. If your connection Teardown syslog says 'SYN Timeout', this implies that the SYN was sent from the Firewall via the destination interface (as in #2 above), but we never received a response (or maybe the server never received the SYN). If you see 'Reset-O' (and the server exists off of the lower-security interface), this is some Layer-3 device (possibly the server) resetting the connection. A 'Reset-I' indicates that the inside host reset the connection (for instance, if the web browser got sick of waiting for the server or user hits 'Stop' on the session).
If you get the syslogs and they don't point you to an obvious answer, send them our way and we'll take a look (mask any IP addresses as you see fit).
Hope that helps,
Kevin
