Sign in
 
HomeOnline20132010Other VersionsLibraryForumsGalleryEHLO Blog
TechCenter >
> 
> 
Telnet fails to Hub transport server from remote sites

Answered Telnet fails to Hub transport server from remote sites

  • Monday, May 17, 2010 6:38 PM
     
     
    Sign In to Vote
    0

    I am receiving an SMTP error 421 4.3.2 error whenever I attempt to telnet to port 25 of our hub transport server from a computer that is in a remote AD site.  There is no error when I do the same thing within the same AD site.  I can't really find anything on this anywhere.  Have tried changing some of the permissions and checking proper IP routing.  Everything seems in order.  Is this normal behavior in Exchange 2007?

    Thanks

    Dennis Ervin

     

All Replies

  • Monday, May 17, 2010 9:55 PM
     
     
    Sign In to Vote
    0
    On Mon, 17 May 2010 18:38:51 +0000, Dennis Ervin wrote:
     
    >
    >
    >I am receiving an SMTP error 421 4.3.2 error whenever I attempt to telnet to port 25 of our hub transport server from a computer that is in a remote AD site. There is no error when I do the same thing within the same AD site. I can't really find anything on this anywhere. Have tried changing some of the permissions and checking proper IP routing. Everything seems in order. Is this normal behavior in Exchange 2007?
     
    It is if you haven't allowed that IP address (or network) access to
    the Receive Connector. Check the "Network" tab on the connector's
    propety page.
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
     
  • Tuesday, May 18, 2010 2:39 AM
     
     
    Sign In to Vote
    0

    Hi,

    From the symptom, that seems the remote IP address is not included in the Receive Connector. By default, the Receive Connector allows the connection from 0.0.0.0-255.255.255.255.

    Please run get-receiveconnector |fl command in EMS, then post the information here.

    Thanks

    Allen

     

     
  • Tuesday, May 18, 2010 1:08 PM
     
     
    Sign In to Vote
    0
    Remote IP address is allowed. 
     
  • Wednesday, May 19, 2010 2:15 AM
     
     
    Sign In to Vote
    0
    On Tue, 18 May 2010 13:08:43 +0000, Dennis Ervin wrote:
     
    >Remote IP address is allowed.
     
    Is there anything more in the stats code? Any explanatory text?
     
    Does the connection attempt show up in the SMTP Receive protocol log
    on server you're connecting to?
     
    Are there any SMTP proxies between the two AD sites?
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
     
  • Wednesday, May 19, 2010 6:49 AM
     
     
    Sign In to Vote
    0

    Hi,

    Whether any firewall was deployed in your environment? If not the firewall issue, please try to disable the Default Receive Connector, and create a new one to teet this issue.

    Thanks

    Allen

     
  • Wednesday, May 19, 2010 5:04 PM
     
     
    Sign In to Vote
    0

    The SMTP Receive protocol log on the Hub Transport server shows exactly the same info as what I see on the remote PC.  The exact message is:

    421 4.3.2 Service not available, closing transmission channel


    Connection to host lost.

     

    No SMTP proxies exist.

     
  • Wednesday, May 19, 2010 5:07 PM
     
     
    Sign In to Vote
    0

    Disabling the Default Receive Connector would interrupt our flow of email.  That is not a viable option.  We already have a second Receive Connector configured for this purpose.

    The only firewall in use is the Windows firewall on the Hub Transport.  It works fine for anything but this and there is nothing in the firewall logs to show a rejected connection.

     
  • Thursday, May 20, 2010 1:30 AM
     
     Answered
    Sign In to Vote
    0
    On Wed, 19 May 2010 17:04:12 +0000, Dennis Ervin wrote:
     
    >The SMTP Receive protocol log on the Hub Transport server shows exactly the same info as what I see on the remote PC. The exact message is:
    >
    >421 4.3.2 Service not available, closing transmission channel
    >
    >Connection to host lost.
     
    That's good. At least it shows that the 421 status originated from
    that HT role.
     
    Is it safe to assume that the receive connector isn't configured to be
    used as an anonymous SMTP relay? Or is it usable for that purpose?
     
    Do you have multiple addresses in the remote-ip ranges on the
    connector? What about authentication methods? Permissions?
     
    get-receiveconnector <connectrorname>|fl
    RemoteIPRanges,AuthMechanism,PermissionGroups
     
    The fact that a simple telnet to port 25 from within the local site
    works but a try from outside the AD site fails sure sounds like an IP
    range restriction problem (assuming the two sites are in different
    networks).
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
    • Marked As Answer by Allen Song Monday, May 31, 2010 2:09 AM
    •  
     
  • Thursday, May 20, 2010 1:31 AM
     
     
    Sign In to Vote
    0
    On Wed, 19 May 2010 17:07:14 +0000, Dennis Ervin wrote:
     
    >
    >
    >Disabling the Default Receive Connector would interrupt our flow of email. That is not a viable option. We already have a second Receive Connector configured for this purpose.
     
    So which receive connector is rejecting the connection? Check the SMTP
    receive log for the connector name.
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
     
  • Tuesday, May 25, 2010 6:32 PM
     
     
    Sign In to Vote
    0

    I have a similar problem.  I have a relay connector set up to allow connections from various servers and devices on the network that need to be able to relay emails anonymously.  Addresses in the AD site work fine, but addresses for devices in the DMZ do not.  The only difference is the address range.  Even if I specify the entire range of that subnet (192.168.168.0/24), I still get a 421 4.3.2 when trying to telnet from any address in that range.  However, if I add all addresses (0.0.0.0-255.255.255.255) then the stupid thing starts working.  Obviously though, allowing all addresses to access an anonymous recieve connector is not an option, even internally.

    This used to work properly but quit allowing connections from this one range somewhere along the way and started throwing the 421.

    Any ideas why this one subnet wouldn't work?

     
  • Wednesday, May 26, 2010 2:02 AM
     
     Proposed Answer
    Sign In to Vote
    0
    On Tue, 25 May 2010 18:32:09 +0000, mikrowiz wrote:
     
    >
    >
    >I have a similar problem. I have a relay connector set up to allow connections from various servers and devices on the network that need to be able to relay emails anonymously. Addresses in the AD site work fine, but addresses for devices in the DMZ do not. The only difference is the address range. Even if I specify the entire range of that subnet (192.168.168.0/24), I still get a 421 4.3.2 when trying to telnet from any address in that range. However, if I add all addresses (0.0.0.0-255.255.255.255) then the stupid thing starts working. Obviously though, allowing all addresses to access an anonymous recieve connector is not an option, even internally.
    >
    >This used to work properly but quit allowing connections from this one range somewhere along the way and started throwing the 421.
    >
    >Any ideas why this one subnet wouldn't work?
     
    Not without knowing the IP address that show up in the SMTP Receive
    protocol log, and that the name of the receive connector in the log
    entry matches the name of the receive connector you think you're
    using.
     
    If you don't want to use the protocol logs then use a network monitor
    and watch for connections from the 192.168.168.0/24 network. If you
    see none that'd be a pretty good hint that the addresses aren't what
    you think they are.
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
    • Proposed As Answer by Jason D Brown Thursday, June 21, 2012 3:43 PM
    •  
     
  • Thursday, June 21, 2012 3:45 PM
     
     
    Sign In to Vote
    0

    Go to a command prompt on the sending server and run ipconif /all and ensure that ALL addresses are in your relay.  It maybe a team or other network flow that is the issue (creating an open relay is never a good idea)

    -Jason