0

I'm trying to send email from a server. Testing on my local machine works fine but on my production Ubuntu server, the webserver fails when trying to send email.

I'm using GMail as my SMTP provider and it appears that the problem is that the production server does not allow access to the Google SMTP server.

The following command established a successful connection on my own machine but fails on the server:

$ openssl s_client -crlf -connect smtp.gmail.com:465 connect: Connection refused connect:errno=111

I've tried various combinations of iptables in case the ports where closed. I've also tried disabling the firewall with ufw disable. Neither has yielded any success for me.

Update:

telnet smtp.gmail.com 465 outputs:

Trying 74.125.143.108... Trying 74.125.143.109... Trying 2a00:1450:4010:c04::6c... telnet: Unable to connect to remote host: Network is unreachable

openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:465 gives me:

connect: Connection refused connect:errno=111

Furthermore iptables-save outputs:

# Generated by iptables-save v1.4.12 on Thu Aug 21 13:06:19 2014 *mangle :PREROUTING ACCEPT [16698:11267219] :INPUT ACCEPT [16698:11267219] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [13015:16282858] :POSTROUTING ACCEPT [13015:16282858] COMMIT # Completed on Thu Aug 21 13:06:19 2014 # Generated by iptables-save v1.4.12 on Thu Aug 21 13:06:19 2014 *nat :PREROUTING ACCEPT [1421:163021] :INPUT ACCEPT [678:92411] :OUTPUT ACCEPT [1339:83461] :POSTROUTING ACCEPT [1339:83461] COMMIT # Completed on Thu Aug 21 13:06:19 2014 # Generated by iptables-save v1.4.12 on Thu Aug 21 13:06:19 2014 *filter :INPUT ACCEPT [9933:3116585] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [12536:16243622] -A INPUT -i lo -j ACCEPT COMMIT # Completed on Thu Aug 21 13:06:19 2014
Improve this question
9
  • Try enabling some additional messaging from openssl: openssl.org/docs/apps/s_client.html, and report back your findings. Commented Aug 21, 2014 at 7:14
  • Is your local machine running Ubuntu too? Commented Aug 21, 2014 at 7:18
  • I'm using smtp.googlemail.com:465 and it works. Try it. Commented Aug 21, 2014 at 7:24
  • @slm: Do you have anything particular in mind? I tried adding a bunch of flags but the error message remained as brief. Commented Aug 21, 2014 at 8:30
  • @garethTheRed: No, it's running Arch Linux. Commented Aug 21, 2014 at 8:31

2 Answers 2

Reset to default
2

IIRC, openssl s_client -connect localhost uses TLS by default.

From https://www.openssl.org/docs/apps/s_client.html:

-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1

These options disable the use of certain SSL or TLS protocols. By default the initial handshake uses a method which should be compatible with all servers and permit them to use SSL v3, SSL v2 or TLS as appropriate.

Unfortunately there are a lot of ancient and broken servers in use which cannot handle this technique and will fail to connect. Some servers only work if TLS is turned off with the -no_tls option others will only support SSL v2 and may need the -ssl2 option.

You might have to use one of these options.

Improve this answer
3
  • 1
    I've already tried those flags. And as I mentioned in the question the command works on my local machine so I'm pretty sure the issue isn't in my usage of the openssl command. Commented Aug 21, 2014 at 8:28
  • Just because it works on one system doesn't necessarily mean it will work on another one. Are you sure that both boxes are 100% identical with regard to installed libraries and versions? Commented Aug 21, 2014 at 8:32
  • I am sure that they are not 100% identical. But as mentioned I did try the options. Furthermore this issue affects my webserver as well. Commented Aug 21, 2014 at 11:11
1

First try basic connectivity to your destination.

telnet smtp.gmail.com 587

If that doesn't work you're probably looking at a firewall issue.

Check that your TLS works

openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

If the first worked but TLS fails you are probably using a deep inspection firewall that blocks you from using TLS (because it can't inspect TLS traffic).

Your problem looks more like a firewall issue than an email issue to me.

If it is you need to describe what you have as a firewall & what it's configuration is. If it's purely iptables, which seems possible on your description to date, paste the output of iptables-save.

Edit

Your iptables configuration is blank. The one rule you do have is irrelevant because the default is ACCEPT anyway, so we can safely ignore iptables.

Because you couldn't even establish a TCP connection (telnet smtp.gmail.com 465) this means you are completely blocked by some firewall assuming everything else is working, eg routing and so on. Because this is a production server I think that can be safely excluded.

So you now need to discuss with your network team or look at your external firewall because you are being blocked on port 465.

Just check port 587 as well as per my examples above, just to see if that port is also blocked. In which case you likely have a very restrictive firewall only allowing related, established and port 25.

You will need to add 465 to the permitted outgoing ports on whatever firewall is blocking you.

I don't know your environment but some high security environments do not allow encryption from inside their network and then have the encryption enforced at the firewall. You may be in this or a similar situation.

Improve this answer
4
  • Thank you. I've added for the commands as you recommended. Commented Aug 21, 2014 at 11:09
  • Just for reference one common userland firewall that does this is Untangle. In bridge mode (iirc) it also manipulates SMTP traffic to remove STARTTLS options in replies. Commented Aug 21, 2014 at 11:26
  • I changed the port number in my question from 587 to 465. That's why the port you mention no longer match the one in my question. Thanks a lot for your answer! I will ask the people who are hosting the server about any external firewalls. Commented Aug 22, 2014 at 6:19
  • I got in touch with the people hosting our server and it turned out to be an external firewall exactly as you suggested! Thanks a lot – I had no idea there existed such a thing as an external firewall. Commented Aug 26, 2014 at 14:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.