Long term your client should consider migrating to the "RPC over HTTPS" connectivity model (single HTTPS connection per client).
http://technet.microsoft.com/en-us/library/bb123741.aspx ////---//// Exchange Server 2003 enabled users to use the Windows RPC over HTTP Proxy component to access their Exchange information from the Internet. This technology wraps remote procedure calls (RPCs) with an HTTP layer. This allows the traffic to traverse network firewalls without requiring RPC ports to be opened. You do not have to use a virtual private network (VPN) to access Exchange servers across the Internet. You must allow only port 443 through your firewall, because Outlook requests use HTTP over SSL. If you already use Outlook Web Access with SSL or Exchange ActiveSync with SSL, you do not have to open any additional ports from the Internet. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Kougoulos Sent: Wednesday, February 25, 2009 5:49 AM To: [email protected] Cc: [email protected] Subject: Re: [c-nsp] Interesting NAToverload issue Hello, you could split the usage of nat pools based on statistics of the source IP addresses eg use 1 ip/overloaded nat pool for even source IPs and another IP for the odd source IPs Best Regards, John On Wed, 25 Feb 2009, [email protected] wrote: > Hi, > > I have a client who has moved their Microsoft Exchange servers to a > service provider location (as part of a de-perimeterization strategy). > These servers are reachable via the Internet. Thus, the client IP are > NATted before they cross the corporate boundary. There are about 45000 > users. Each user needs about 17-22 sessions (that's how MS Outlook > works) and thus as many NAT entries Therefore a NAT pool is used with > overload. It was working fine for more than a year now but suddenly the > following phenomenon has been noticed. - When a user session is being > built up and he has let's say 10 NAT entries using the first IP in the > NAT pool and the port numbers run out, the next IP in the NAT pool is > used to complete the required number of sessions. - Exchange server is > apparently not happy with one client using 2 IP addresses and keeps > (re-)building sessions untill all of them are using the same NATted IP. > This can sometimes take upto 5 miniutes. > > Is there a solution to this problem? There is one single destination > global address. Is there a way to force the usage of the same IP from > the NAT pool for all NAT requests from a particular source IP? Platform > is7206-vxr with NPE-G2 > > Thanks in advance > > > Nasir Shaikh > This email contains information from BT Nederland N.V., which may be privileged or confidential. > It's meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. > If you have received this email in error, please let me know immediately on the email address above. > We monitor our systems, and may record your emails. > > BT Nederland N.V. > Registered office: Offices Minerva and Mercurius, Herikerbergweg 2, 1101 CM Amsterdam > Registered at the Amsterdam Chamber of Commerce no: 33296214 > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
