Ubuntu 14.01 Host / Ubuntu 14.01 Container; Postfix does not send mail; telnet does not connect to outside host - telnet

==== 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

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!!

Related

iptables DNAT does not work port forwarding between 2 interface

I have one interface which visible to my network, and a loopback (127.0.0.1),
ens192 -> 192.168.22.100
lo -> 127.0.0.1
I have a service running on lo interface on port 3333, and I want to reach that port via ens192 via port 4444
192.168.22.100:4444 -> 127.0.0.1:3333
I have tried all available solutions on StackOverflow it doesn't work.
sysctl -w net.ipv4.conf.[IFNAME].route_localnet=1
iptables -t nat -A PREROUTING -p tcp -d 192.168.22.100 --dport 4444 -j DNAT --to 127.0.0.1:3333
iptables -A INPUT -i ens192 -p tcp --dport 4444 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ens192 -p tcp --sport 4444 -m state --state ESTABLISHED -j ACCEPT

Redirection using iptables

I have a server on cloud with following iptables.
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 443 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 9200 -m state --state New,RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -j DROP
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2900 -j DNAT --to-destination 127.0.0.1:9200
What I have to add in other chains so that i can access my service on 2900 port.
Rules apply from the top down.
6.2 Destination NAT
This is done in the PREROUTING chain, just as the packet comes in; this means that anything else on the Linux box itself (routing, packet filtering) will see the packet going to its `real' destination
https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html#ss6.2
So you want the PREROUTING line at the top, so the NAT happens first.
Then an INPUT entry allowing incoming connections on your destination port, after NAT.
Except, what's up with your INPUT rules not accepting RELATED and ESTABLISHED and your output rules setting specific source ports? Outbound traffic usually comes from random high ports.
From https://serverfault.com/a/578781/57144 and https://serverfault.com/a/578787/57144 you want to explicitly say NEW connections for incoming ports, and should prefer fewer rules for performance (if applicable).
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2900 -j DNAT --to-destination 127.0.0.1:9200
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 9200 -j ACCEPT
# or
# iptables -A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 80,443,9200 -j ACCEPT
iptables -A INPUT -j DROP

Squid 2.6 and https_port

I have a question about Squid configuration as trasparent proxy using SSL.
I would to use Squid 2.6 as trasparent proxy with http and https connection.
I followed this steps:
1) I configurated my iptables:
# Generated by iptables-save v1.4.7 on Wed Nov 9 13:37:50 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10363:2864591]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth+ -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth+ -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Wed Nov 9 13:37:50 2011
# Generated by iptables-save v1.4.7 on Wed Nov 9 13:37:50 2011
*nat
:PREROUTING ACCEPT [4:650]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3129
COMMIT
2) I configurated my squid.conf about http_port and it work well.
3) About SSL I setted this:
https_port 3129 transparent key=/etc/squid/ssl/myhost.com-private.pem
cert=/etc/squid/ssl/myhost.com-certificate.pem
but about https not work.
If I use this command lsof -n -i -P | grep squid
about the squid I see also:
squid 6483 squid 6u IPv4 155998 0t0 UDP *:43053
squid 6483 squid 13u IPv4 156001 0t0 TCP *:3128 (LISTEN)
squid 6483 squid 14u IPv4 156003 0t0 UDP *:3130
and I not see 3129 port. Is correct this way?
Any suggestions?

keepalived works well without iptables

I have setup keepalived, and it works well only when I stop the iptables service. My iptables config like this, Please tell me what rules should added for keepalived
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 6379 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
Just slove this problem these days,Haha
Do:
iptables -I INPUT -d 224.0.0.0/8 -j ACCEPT
iptables -I INPUT -p vrrp -j ACCEPT
You must accept ip protocol 112 (vrrp) and multicast traffic to 224.0.0.18. If you are using auth_type AH then you must accept proto 51
iptables -I INPUT -p 112 -d 224.0.0.18 -j ACCEPT
iptables -I INPUT -p 51 -d 224.0.0.18 -j ACCEPT
to MASTER keepalived machine:
iptables -I OUTPUT -p vrrp -s 192.168.10.1 -d 224.0.0.0/24 -j ACCEPT
to BACKUP keepalived machine:
iptables -I INPUT -p vrrp -s 192.168.10.1 -d 224.0.0.0/24 -j ACCEPT
192.168.10.1 is the master keepalived ip

How to allow mail through iptables?

I'm securing my server (with iptables) so that only http and ssh ports are open and that is fine, although I use the mail command (server: CentOS 6.2) in some applications and it does not get through now thanks to iptables blocking everything.
What ports do I allow it access to?
Mail usage: echo "{{message}}" | mail -s "{{subject}}" me#mail.com
I've tried the standard mail port 25, but I have had no success with that.
Here is the current setup:
iptables --flush
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# incoming ssh
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
# outgoing ssh
iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
#HTTP
iptables -A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
# mail (does not work)
iptables -A INPUT -i eth0 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT
(EDIT) ANSWER: The working iptables rule:
iptables -A OUTPUT -o eth0 -p tcp --sport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT
The OUTPUT commands should also refer to --dport, not --sport. You'll also want to allow NEW outgoing packets in order to initiate the connection to the SMTP server.
In general, however, since OUTPUT controls only those packets that your own system generates, you can set the OUTPUT policy to ACCEPT unless you need to prevent the generation of outgoing packets.
Two more comments:
1. Jay D's suggestion to "allow everything and then start blocking specific traffic" is insecure. Never configure iptables this way because you'd have to know in advance which ports an attacker might use and block them all individually. Always use a whitelist instead of a blacklist if you can.
2. A hint from the trenches: when you're debugging iptables, it's often helpful to -Insert and -Append log messages at the beginning and end of each chain, then clear the counters, and run an experiment. (In your case, issue the mail command.) Then check the counters and logs to understand how the packet(s) migrated through the chains and where they may have been dropped.