Fix the routing. We route a mixture of RFC1918 and public addresses on our networks with no problems. And we've got a LOT of networks.
------------------------------------------------------ Roger D. Seielstad - MCSE Senior Systems Administrator Peregrine Systems Atlanta, GA http://www.peregrine.com > -----Original Message----- > From: John Q [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 10, 2002 2:31 PM > To: Exchange Discussions > Subject: Re: Exchange 5.5 over WAN connection (new mail notifications) > > > Yes, & I know it does not work on NATed addresses. > I was just hoping some one had a easy fix. > > -John Q Jr. > > ----- Original Message ----- > From: "Morgan, Joshua" <[EMAIL PROTECTED]> > To: "Exchange Discussions" <[EMAIL PROTECTED]> > Sent: Thursday, January 10, 2002 11:25 AM > Subject: RE: Exchange 5.5 over WAN connection (new mail notifications) > > > Is the Internet address that they are being translated to a > NAT address ? > > > > > > PROFITLAB > Network Engineer > PH: (864) 250-1350 Ext 133 > [EMAIL PROTECTED] > > > > -----Original Message----- > From: John Q [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 10, 2002 12:04 PM > To: Exchange Discussions > Subject: Re: Exchange 5.5 over WAN connection (new mail notifications) > > > I am having a serious problem with "new mail notifications" > over a WAN. Basically they don't update until a user clicks > on a nether message or waits in excess of 20 minutes. > Needless to say users are frustrated by this due to the fact > that they don't "think" their mail has been sent. Is there a > work arround for this? Client side notification of disabeling > "new mail notifications"? The description of why this > particular situation does not work is below, read into if you wish. > > -John Q Jr. > > Currently machines on the WAN network are using internal IP > addresses (which are not routable via our network). When the > machines send packets to our network, the WAN router > converts the IP addresses into a public IP address (an > address our router can actually reply to). The problem in > hand is that when Exchange receives packets from the client, > it looks into the payload information (information inside the > packet, not the header) to figure out where it should be sent. > > Case in point: Workstation 10.10.2.15 is connected to > x.230.24156/57. Due to NAT, the Exchange servers sees > x.154.10.42 connected (it can communicate back fine). Once > the user receives a piece of mail, the Exchange server > replies to 10.10.2.15 (it had to have looked this information > up from the payload data) and of course this IP is not routable. > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
