I think the first explanation and solution will give you the desired results you are looking for. The problem with IPSEC ESP protocol(I'll assume you are not use AH, since it normally isn't deployed in your type of scenerio, and that you have a general understanding of the two protocols) is that ESP has no port associated with it once a tunnel is built. Actually it does, but only the terminating end tunnel server knows what to do with it. When your users build a tunnel from behind a PAT device(port address translation=layer 4, not NAT which is layer 3 and doesn't care about port numbers), the PAT device which is most likely a home firewall of some flavor does not know how to keep track of inbound IPSEC replys from the tunnel server because it doesn't see a port number associated with that connection, so it has no way to keep track of the connection in it's PAT table and drops it completely. Basically, the end user is locking himself out because of his own PAT device (I use the acronym PAT here since PAT and NAT are somewhat different, and it's important to know this). One of the cool features of the 3000 is that it has the ability to encapsulate ESP with a 22-bye header of any udp port number you prefer(keep it high, like 7777, and you need the latest code running on the 3000 for the ability to choose a port number). Once you do this, all the PAT device see's is a udp XXXX port number, and can keep track of the session, making life smoother for you and your users. Just make sure the same number port is configured on both the concentrator and the server. I think the feature is called UDP through NAT on the 3000 under groups, IPSEC, and NAT transparency on the 5000.
Second scenario. Before this configurable NAT trasparency feature, the port was hardcoded both for the 3000 and 5000, I think, and it was TCP 80, making it look like an http request. If you have not enabled this feature, AT&T most likely has deployed a proxy firewall, screening ESP traffic, which will block your request(I don't think this is the case). If indeed you did use this feature, and it was tcp 80 for the encapsulating port number, the proxy server would most likely try to validate and cache this http request, which in turn is actually a VPN tunnel, and will look like a bogus http request to the proxy, failing the tunnel altogether. I hope this helps you, and I hope I made the explanation as clear as possible.
