Solved

Exchange 2010 unable to recieve external emails when firewall points to it

Posted on 2010-09-06
14
498 Views
Last Modified: 2012-05-10
Have recently installed Exchange 2010 into an existing 2003 Organisation. Currently everything is coexisting fine and we are able to send and receive emails. Users with legacy exchange mailboxes can access OWA using https://oldexchangeserver/exchange internally and https://mail.ourdomainname.com/exchange

I have moved some test mailboxes to the 2010 server and can access using webapp at https://newexchangeserver/owa internaly

(please note i have not setup a legacy namespace as i plan to move all mailboxes soon as there are not many)

Our firewall does basic nat translation to the oldexchange server. If i change the nat rule to the new exchange server I can no longer receive emails externally and I cannot connect to https://mail.ourdomainname/owa

i cant see it as the nat rule itself as all i am doing is changing the server it is pointed to and have confirmed this is OK

I have setup the receive connector to accept anonymous users here is the output of the command get-receiveconnector :fl

RunspaceId                              : 1e98eadc-b558-42c9-ae54-0e0aca28b504
AuthMechanism                        : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Banner                                     :
BinaryMimeEnabled                  : True
Bindings                                   : {:::25, 0.0.0.0:25}
ChunkingEnabled                         : True
DefaultDomain                           :
DeliveryStatusNotificationEnabled       : True
EightBitMimeEnabled                     : True
DomainSecureEnabled                     : False
EnhancedStatusCodesEnabled              : True
LongAddressesEnabled                    : False
OrarEnabled                             : False
SuppressXAnonymousTls                   : False
AdvertiseClientSettings                 : False
Fqdn                                    : EXCHANGE2010.ourdomain.local
Comment                                 :
Enabled                                 : True
ConnectionTimeout                       : 00:10:00
ConnectionInactivityTimeout             : 00:05:00
MessageRateLimit                        : unlimited
MessageRateSource                       : IPAddress
MaxInboundConnection                    : 5000
MaxInboundConnectionPerSource           : unlimited
MaxInboundConnectionPercentagePerSource : 100
MaxHeaderSize                           : 64 KB (65,536 bytes)
MaxHopCount                             : 30
MaxLocalHopCount                        : 8
MaxLogonFailures                        : 3
MaxMessageSize                          : 10 MB (10,485,760 bytes)
MaxProtocolErrors                       : 5
MaxRecipientsPerMessage                 : 5000
PermissionGroups                        : AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers
PipeliningEnabled                       : True
ProtocolLoggingLevel                    : None
RemoteIPRanges                          : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}
RequireEHLODomain                       : False
RequireTLS                              : False
EnableAuthGSSAPI                        : False
LiveCredentialEnabled                   : False
Server                                  : BENEXCH
SizeEnabled                             : EnabledWithoutValue
TarpitInterval                          : 00:00:05
MaxAcknowledgementDelay                 : 00:00:30
AdminDisplayName                        :
ExchangeVersion                         : 0.1 (8.0.535.0)
Name                                    : Default EXCHANGE2010
DistinguishedName                       : CN=Default EXCHANGE2010,CN=SMTP Receive Connectors,CN=Protocols,CN=EXCHANGE2010,CN=Serv
                                          ers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Grou
                                          ps,CN=Our Company,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC
                                          =domain,DC=local
Identity                                : EXCHANGE2010\Default EXCHANGE2010
Guid                                    : 413ac4f1-dafa-44e9-b1f4-050425e8d1b9
ObjectCategory                          : domain.local/Configuration/Schema/ms-Exch-Smtp-Receive-Connector
ObjectClass                             : {top, msExchSmtpReceiveConnector}
WhenChanged                             : 7/09/2010 9:45:38 AM
WhenCreated                             : 4/09/2010 11:55:29 AM
WhenChangedUTC                          : 6/09/2010 11:45:38 PM
WhenCreatedUTC                          : 4/09/2010 1:55:29 AM
OrganizationId                          :
OriginatingServer                       : OURDC.benrad.local
IsValid                                 : True
0
Comment
Question by:PACSAdmin
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 6
14 Comments
 
LVL 32

Expert Comment

by:endital1097
ID: 33614318
update your receive connector to allow anonymous connections on the permissions group tab for the "Default SERVER" receive connector
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33614330
sorry, re-reading :)
0
 
LVL 6

Author Comment

by:PACSAdmin
ID: 33614332
I knew that would be the first comment so i specificlly wrote

"I have setup the receive connector to accept anonymous"

0
Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
LVL 6

Author Comment

by:PACSAdmin
ID: 33614334
thats OK  i hid it at the bottom
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33614342
that's what happens when you have a kid talking to you while on the phone and reading a post :)
0
 
LVL 32

Accepted Solution

by:
endital1097 earned 500 total points
ID: 33614364
have you tried to establish a telnet session from an external source on port 25?
your receive connector looks good, the remote ip ranges are all inclusive, you have anonymous (as stated too)
i would enable the logging on the connector to verbose and check the log

do you have another receive connector configured (other than client)?
0
 
LVL 6

Author Comment

by:PACSAdmin
ID: 33614395
I have no other receive connectors other than client.

Can telnet to it internally but not externally.
0
 
LVL 32

Assisted Solution

by:endital1097
endital1097 earned 500 total points
ID: 33614418
you changed the nat translation which in some cases will move all traffic to the new server
double check the port forwarding rules to ensure that 80,443,and 25 are going to the correct server

enabling the logging on the receive connector should show the lack of connections
0
 
LVL 6

Author Comment

by:PACSAdmin
ID: 33614511
Not quite sure what you are getting at?

I am changing the nat rules that are setup to route  25 and 443 to the new exchange2010 Server. I want 25 and 443 to go directly to the new exchange receive connector to test OWA and email connectivity to the new server before i move all the mailboxes over and decommision the old exchange server.

I was assuming that once 25 and 443 were directed to the New Server that i would be able to access https://mail.ourdomain.com/owa and receive emails through this connector and have them route to the 2010 mailboxes. Is this assumption wrong or does mail flow still need to go though the old server

0
 
LVL 32

Expert Comment

by:endital1097
ID: 33614564
No that is correct
Enable logging and see if the connection reaches your server
0
 
LVL 6

Author Comment

by:PACSAdmin
ID: 33614652
I checked that under Server configuration -- Hub Transport -- Log settings tab that logging was enabled

also clicked on manage Diagnostic Logging properties and upped the logging properties for smtpReceive  to expert

changed the nat back to the new server and attempted to send an email from outside into our mail server

checked under the "..\logs\protocolLog\SmtpReceive" directory. The location is empty so am i gueesing right in saying the smtp receive connector is not getting hit.

0
 
LVL 6

Author Comment

by:PACSAdmin
ID: 33614692
also checked the nat rules logging on the Cisco ASA and that seems ok too seems to be translating the address OK
0
 
LVL 6

Author Comment

by:PACSAdmin
ID: 33615075
fixed it.

Installed wireshark on exchange server and verified 25 and 443 was hitting it so it had to be a routing issue. Turned out to be simple misconfiguration of gateway.

0
 
LVL 6

Author Closing Comment

by:PACSAdmin
ID: 33615081
even though i fixed the issue myself i am awarding points to endital for pointing me in the right direction which ultimatly led to resolution
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Background Information Recently I have fixed file server permission issues for one of my client. The client has 1800 users and one Windows Server 2008 R2 domain joined file server with 12 TB of data, 250+ shared folders and the folder structure i…
A company’s centralized system that manages user data, security, and distributed resources is often a focus of criminal attention. Active Directory (AD) is no exception. In truth, it’s even more likely to be targeted due to the number of companies …
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

738 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question