-2

==== Basic information ====

  • iRedMail version (check /etc/iredmail-release): iRedMail-0.9.5-1

  • Linux/BSD distribution name and version: Ubuntu 14.01 container inside Ubuntu 14.01 TurnkeyLinux Core

  • Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL

  • Web server (Apache or Nginx): Apache

  • Postfix log excerpt:

    Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: connect from x.y.z[127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: Anonymous TLS connection established from x.y.z[127.0.0.1]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

    Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: 6EEA060306: client=x.y.z[127.0.0.1], sasl_method=LOGIN, sasl_username=address@x.y.z

    Jan 6 10:24:38 iredmail postfix/cleanup[2636]: 6EEA060306: message-id=

    Jan 6 10:24:38 iredmail roundcube: User iaaberga [192.168.121.1]; Message for destination@gmail.com; 250: 2.0.0 Ok: queued as 6EEA060306

    Jan 6 10:24:38 iredmail postfix/qmgr[2587]: 6EEA060306: from=, size=575, nrcpt=1 (queue active)

    Jan 6 10:24:38 iredmail postfix/submission/smtpd[2631]: disconnect from x.y.z[127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/smtpd[2648]: connect from x.y.z[127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/smtpd[2648]: C97F262D1B: client=x.y.z[127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/cleanup[2636]: C97F262D1B: message-id=

    Jan 6 10:24:38 iredmail postfix/qmgr[2587]: C97F262D1B: from=, size=1628, nrcpt=1 (queue active)

    Jan 6 10:24:38 iredmail postfix/smtpd[2648]: disconnect from x.y.z[127.0.0.1]

    Jan 6 10:24:38 iredmail amavis[1742]: (01742-01) Passed CLEAN {RelayedInternal}, ORIGINATING/MYNETS LOCAL [127.0.0.1]:35413 -> , Queue-ID: 6EEA060306, Message-ID: , mail_id: 4QjhhYZODSHf, Hits: -2.986, size: 575, queued_as: C97F262D1B, dkim_new=dkim:y.z, 328 ms, Tests: [ALL_TRUSTED=-1,RP_MATCHES_RCVD=-3.199,TVD_RCVD_SINGLE=1.213]

    Jan 6 10:24:38 iredmail postfix/smtp[2642]: 6EEA060306: to=, relay=127.0.0.1[127.0.0.1]:10026, delay=0.4, delays=0.05/0.01/0.01/0.33, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as C97F262D1B)

    Jan 6 10:24:38 iredmail postfix/qmgr[2587]: 6EEA060306: removed

    Jan 6 10:24:47 iredmail postfix/smtp[2618]: connect to mx6.mail.icloud.com[17.172.34.71]:25: Connection timed out

    Jan 6 10:24:47 iredmail postfix/smtp[2622]: connect to alt1.gmail-smtp-in.l.google.com[173.194.69.27]:25: Connection timed out

====

Hi!

I did install iRedmail as an lxc container on an Ubuntu 14.01 / Ubuntu 14.01 host/container system.

While I can receive emails, Postfix does not send messages (that appear to be sent out in the webmail client, but do never arrive at dest).

From the container level connectivity seems to work in general: I can ssh to some host I have access to; I can use apt-get tools to install new sw, etc.

Trying to telnet alt1.gmail-smtp-in.l.google.com on port 25 does not succeed (if done from inside the container).

root@iredmail ~# telnet alt1.gmail-smtp-in.l.google.com 25
Trying 173.194.69.26...

Eventually the connection will fail.

If I do exit from the container and try the same telnet connection, all is well

root@lxc ~# telnet alt1.gmail-smtp-in.l.google.com 25
Trying 173.194.69.27...
Connected to alt1.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP t19si1302495wrb.232 - gsmtp
QUIT
221 2.0.0 closing connection t19si1302495wrb.232 - gsmtp
Connection closed by foreign host.

This is the container's iptables config:

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12320 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12321 -j ACCEPT

# Mail SMTP
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A FORWARD -p tcp -d 192.168.121.1 --dport 25 -j ACCEPT

# POP3
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT

# SMTPS
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
# IMAPS
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
# IMAPS - 2
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

COMMIT

I am not familiar with containers' networking, so I might very well missing anything obvious!

It does not look to be a problem with Postfix config..

Thanks for any help,

Aldo

aaberga
  • 217
  • 1
  • 2
  • 8
  • So, to recap: the Ubuntu 'host' can telnet to Google. The Ubuntu 'container' can not telnet to Google, but has no problem with SSH or apt-get. And it receives email throught the host (that is on AWS). – aaberga Jan 06 '17 at 18:57
  • flush iptables rules in the container, change policies to accept and retry. if there is a problem with your iptables rules your telnet should work. another thing would be restarting containers service on ubuntu host and start the container and try again. – Farhad Farahi Jan 07 '17 at 04:52
  • Thanks Farhad, but this does not help. I know now roughly what goes wrong. As I suspected to have edit the container's iptables settings in an uncontrolled way, I created a second container and got to see what iptables settings look like there. As I was at it, I did try the root@iredmail2 ~# telnet alt1.gmail-smtp-in.l.google.com 25 command... Trying ... Connected to alt1.gmail-smtp-in.l.google.com. Escape character is '^]'. 220 ESMTP Postfix QUIT 221 2.0.0 Bye Connection closed by foreign host. – aaberga Jan 07 '17 at 12:53
  • Now the connection succeeded, but diverted. I was actually talking to the first container instance!! That seems like the host is intercepting all nat-outgoing port 25 connections and resending them to the first container. It is reasonable to assume that even from inside this happens, but not closing the loop. Anyway: my question resolves to how to correct the 'host-side' iptables settings, so that everything from the outside world and meaning email is forwarded to the first container. AND: every connection request from inside the containers to the 'outside' is left untouched... – aaberga Jan 07 '17 at 12:53

1 Answers1

0

As it often happens (once you know the solution) the problem was trivial...

In short: a wrong NAT setting in the host was intercepting and forwarding traffic from all sources, CONTAINERS INCLUDED!!

This is the relevant part of the HOST'S iptables rules as it was:

*nat
:PREROUTING ACCEPT [22532:1479233]
:INPUT ACCEPT [22432:1472721]
:OUTPUT ACCEPT [11623:812922]
:POSTROUTING ACCEPT [2959:155572]
-A PREROUTING -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.121.174:25
-A PREROUTING -p tcp -m tcp --dport 110 -j DNAT --to-destination 192.168.121.174:110
-A PREROUTING -p tcp -m tcp --dport 143 -j DNAT --to-destination 192.168.121.174:143
-A PREROUTING -p tcp -m tcp --dport 465 -j DNAT --to-destination 192.168.121.174:465
-A PREROUTING -p tcp -m tcp --dport 587 -j DNAT --to-destination 192.168.121.174:587
-A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination 192.168.121.174:993
-A PREROUTING -p tcp -m tcp --dport 995 -j DNAT --to-destination 192.168.121.174:995
-A POSTROUTING -o br0 -j MASQUERADE
-A POSTROUTING -s 192.168.121.0/24 ! -o natbr0 -j MASQUERADE
COMMIT

It tells iptables to pass all traffic say to port 25 to the virtual address of the mail server container. This happens even for traffic from the container itself.

BINGO!!

Now this is the correct setting, where br0 is the AWS network interface that links to the outside world. So, only packets arriving there first, should be routed to the NATted virtual address of the email server package.

*nat
:PREROUTING ACCEPT [22532:1479233]
:INPUT ACCEPT [22432:1472721]
:OUTPUT ACCEPT [11623:812922]
:POSTROUTING ACCEPT [2959:155572]
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 25 -j DNAT --to-destination 192.168.121.174:25
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 110 -j DNAT --to-destination 192.168.121.174:110
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 143 -j DNAT --to-destination 192.168.121.174:143
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 465 -j DNAT --to-destination 192.168.121.174:465
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 587 -j DNAT --to-destination 192.168.121.174:587
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 993 -j DNAT --to-destination 192.168.121.174:993
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 995 -j DNAT --to-destination 192.168.121.174:995
-A POSTROUTING -o br0 -j MASQUERADE
-A POSTROUTING -s 192.168.121.0/24 ! -o natbr0 -j MASQUERADE
COMMIT

Obviously without the interception loop the email server inside the container easily sends mail out!!

aaberga
  • 217
  • 1
  • 2
  • 8