Telnet issues
We have a Exchange Server 2013 CU3 and are trying to make a connection from the internet.  The netowork seems to be NATing the packets correctly for the Exchange server but when we try to telnet in to the public IP for the server, it says waits a while and says "connection to host lost"  No banner.  No other useful info.  I am trying to determine if the smtp taffic is getting to the server and the server is just discarding it or if the packets are lost in the network path.  Is there a log that shows all smpt connections to the server?  I did protocol logging on the default recieve connector and there doesn't seem to be anything for the attempts.  Does anyone have some advice.  I am out of ideas.  Thank you in advance.
March 20th, 2014 8:37pm

It sounds like you're saying traffic isn't getting in from the outside world.  The NATing device should be doing all the work.  The Exchange server should only have it's internal IP and have a receive connector for that internal IP.  The Firewall/Router/NAT device should be listening on the external IP on the port (example 65.x.x.12:25) and then it should translate that and forward the packets to the appropriate server.

Outside to public listener -> 64.x.x.12:25 ->to device-> to internal server -> 192.168.x.25:25

Traffic going out is easier because DNS resolves the destination, then the server just uses it's gateway to get out.  Sending is the easy part, receiving is trickier.

Free Windows Admin Tool Kit Click here and download it now
March 20th, 2014 10:49pm

Our Exchange server only has configured an ip for the internal network.  I guess that I don't understand the relay connectors to well.  The server has both roles for CAS and Mailbox installed and so has the 5 connectors created by default.  This should allow a telnet connection from outside the network by default right?

I don't understand what you mean by having a recieve connector for that IP.  With only one server I assumed that all connectors have to do with that one Ip.  I assume that the server works the same with external emails getting picked up by the recieve connector for the CAS server.  This doesn't have any differentiation for IPs other than covering all incoming server addresses for ports 25 and 2525.

Like I previously mentioned, the NATing seems to work.  When tracking packets through the firewall the NATing and unNATing show good.

What my boss who comes from an Exim and Zimbra linux background wants is a list of all smtp connections to the server.  Be they emails or telnet connections.  I am having a hard time meeting that expectation.  Do you have any thoughts.

March 21st, 2014 6:18pm

Our Exchange server only has configured an ip for the internal network.  I guess that I don't understand the relay connectors to well.  The server has both roles for CAS and Mailbox installed and so has the 5 connectors created by default.  This should allow a telnet connection from outside the network by default right?

I don't understand what you mean by having a recieve connector for that IP.  With only one server I assumed that all connectors have to do with that one Ip.  I assume that the server works the same with external emails getting picked up by the recieve connector for the CAS server.  This doesn't have any differentiation for IPs other than covering all incoming server addresses for ports 25 and 2525.

Like I previously mentioned, the NATing seems to work.  When tracking packets through the firewall the NATing and unNATing show good.

What my boss who comes from an Exim and Zimbra linux background wants is a list of all smtp connections to the server.  Be they emails or telnet connections.  I am having a hard time meeting that expectation.  Do you have any thoughts.

Free Windows Admin Tool Kit Click here and download it now
March 21st, 2014 6:18pm

I figured it out.  So when setting protocol logging, it is a good idea that you understand exactly which logs to look at.  I was looking at the HUB server logs and not the front end logs.  This showed me all connections to the exchange server.

The NATing issue was complicated.  It got resolved.  Thank you for the help.

March 21st, 2014 8:05pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics