Telnet into outgoing interface on IronPort

[bglasgow11]

I'm in the process of rolling out a C300V (9.7.1) and am getting stuck on outgoing mail.

The design is 1 management, 1 incoming and 1 outgoing interface.  Incoming mail is working fine - no problems.  Outgoing mail is a different issue.  Network group has opened port 25 from my exchange hub/cas server to the outgoing interface, but I cannot telnet to it from the CAS server. I had them reverify that port 25 was open from the cas server to the c300v outgoing interface.  I can ping the outgoing interface just fine.  I have set up the relay in the HAT RELAYLIST with the proper IP of the CAS server and as priority 1.  Shouldn't I be able to telnet into the outgoing interface on the c300v? 

From the documentation floating around, I've done everything and the setup makes logical sense.

Anyone have any ideas?  Thanks!  brent

[dmccabej]

Hello Brent,

Do you have the 'Outgoing' interface (IF) tied to a specific 'Outgoing' listener? We do not start actually listening on that port until a listener is tied to the IF. So, you may need to create a new listener specifically for that IF. 

If that's accomplished, you can perform the netstat -n command from the CLI and confirm that the IF is shown in a LISTEN state for port 25.

Also, you never mentioned the telnet command you're testing with. I'm assuming you're using telnet x.x.x.x 25 and not just telnet x.x.x.x?

Thanks

-Dennis M.

[bglasgow11]

Hi Dennis, Thanks for the quick response. The IF is tied to outgoing listener  on port 25 and is the Private type of listener.  The nslookup -n shows "tcp4 0 0 x.x.x.30.25 (local interface address)   *.*   listen", so it looks to be listening.

Telnet command is    telnet x.x.x.30 25

Is there anything else to check before I go back to the networking guys?

Thanks for the help!

Brent

[dmccabej]

Hello Brent,

You're very welcome!

As a last check, you can also try to telnet on the ESA itself (so from itself, to itself) to double confirm the ip/port is indeed listening and working. If you're able to successfully telnet on the ESA to it's own IP over port 25, then I would most likely assume there's a networking issue somewhere between Exchange and the ESA.

If you need us to dig deeper on the ESA side, I would suggest opening a TAC case and we can help take a closer look.

Hopefully that helps!

Thanks!

-Dennis M.

[bglasgow11]

It connected right away and then disconnected itself when telnetting from itself.

Here the output:

Trying x.x.x.30....

Connected to x.x.x.30.

Escape character is '^]'.

554 outgoing.servername.domainname.com

connection closed by foreign host.

Thanks!  Brent

[dmccabej]

Hello Brent,

It looks like we may be getting that error since the ESA address itself isn't listed in the RELAYLIST (or however you named it) Sender Group for that Outbound listener. For testing purposes, you can try going to the following in the GUI and then adding in the IP addresses for the ESA itself, submit/commit and then try to telnet again. 

Mail Policies --> HAT Overview --> Listener Drop-Down --> Select your Outbound listener --> Edit your RELAYLIST Sender Group --> Add sender and add in the IP addresses of the ESA

If not done already, you'll also want to make sure that is where you entered in the Exchange IP addresses, on the RELAYLIST of the correct listener. (and not on the Inbound listener)

Thanks

-Dennis M.

[bglasgow11]

thanks - that worked for the telnet selfie.

Now I'm off to the network team.  Thanks for all your help!

-Brent

[dmccabej]

You're very welcome! If you run into anything else let us know. :)

Thanks!

-Dennis M.

[bglasgow11]

interesting - I ran a packet capture on the ESA box when attempting to telnet in from my cas server.  We have communication going on, but a lot of re-transmissions, etc.

The capture looks like this (it is test IPs):

the 131.71 is the cas server and the 36.30 is the ironport server.  I don't see anything odd, other than the re-transmissions, which I'm looking into now.

Let me know if you see something I'm missing.  Thanks again for your help!

[dmccabej]

Hello Brent,

It looks like for some reason the packets going from the ESA back over to the CAS are getting lost/dropped somewhere in the chain. The CAS is able to send us the 'SYN' to start the TCP handshake, but when we send the 'SYN, ACK' back to the CAS we never receive a response.

It definitely appears network related, so I would have your network team check all hops on the path when trying to perform the telnet. 

Thanks!

-Dennis M.

[Libin Varghese]

Hi

The re-transmissions would suggest a network issue which is preventing the TCP handshake process from completing.

This would result in the telnet failing as well.

- Libin

[bglasgow11]

OK - it is a routing issue.  If I point the default route on the device to the DG of the outgoing interface, telnet and outgoing email works.  If I point the default route to the DG of the incoming interface, incoming mail works properly.

Now I'm looking at that issue...

[dmccabej]

Hello Brent,

If you need to, you can also add additional routes via Network --> Routing in the GUI. That way, you can tell the system to use a specific gateway for a specific network. That sounds like it may help your issue.

Thanks!

-Dennis M.