I have several external POP accounts with many email service providers. I use the Outlook desktop app to check email on all of those accounts. I use port 995 to check email on all accounts. The Outlook client is behind a gateway firewall which has a rule to allow traffic out on port 995.
I installed MIAB on an external server. It seems to be working fine. I can send and receive emails but why is it that only MIAB tries to initiate a separate connection back to me, from port 995, each time I check email? These separate connections are being blocked by the gateway firewall, as they should be.
2021:06:25-02:13:21 gateway ulogd[600]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="22:f7:c0:c9:06:55" dstmac="a2:ba:db:e6:cd:54" srcip="<public IP of MIAB server>" dstip="<public IP of Outlook client>" proto="6" length="40" tos="0x00" prec="0x20" ttl="56" srcport="995" dstport="58354" tcpflags="RST"
2021:06:25-02:13:21 gateway ulogd[600]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="22:f7:c0:c9:06:55" dstmac="a2:ba:db:e6:cd:54" srcip="<public IP of MIAB server>" dstip="<public IP of Outlook client>" proto="6" length="40" tos="0x00" prec="0x20" ttl="56" srcport="995" dstport="58354" tcpflags="RST"
2021:06:25-02:15:21 gateway ulogd[600]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="22:f7:c0:c9:06:55" dstmac="a2:ba:db:e6:cd:54" srcip="<public IP of MIAB server>" dstip="<public IP of Outlook client>" proto="6" length="40" tos="0x00" prec="0x20" ttl="55" srcport="995" dstport="58594" tcpflags="RST"
2021:06:25-02:15:21 gateway ulogd[600]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="22:f7:c0:c9:06:55" dstmac="a2:ba:db:e6:cd:54" srcip="<public IP of MIAB server>" dstip="<public IP of Outlook client>" proto="6" length="40" tos="0x00" prec="0x20" ttl="55" srcport="995" dstport="58594" tcpflags="RST"
So every time I use Outlook to check email on the MIAB server, my firewall blocks connections from port 995 of the MIAB server. I do not see this type of behavior from any other external email server that I connect to.
I have to admit it’s been some time since I figured things out at this level, but MiaB is just responding on the ports that were established. I’m pretty sure MiaB has to use the ports the state was created on. As to why MiaB is making the connection, I’m not sure. It could be to maintain the state entry thing (really technical here, am I) for push notification or for the https session? Also not sure why your router is blocking the traffic, but it does seem something specific to your router else we would have a forum full of people needing help with this issue.
I am assuming you have not otherwise modified MiaB.
No mods to MiaB. I just find it odd that no other POP server, that I connect to, does this.
My gateway device is Sophos UTM which has explicit firewall rules.
Is it just the TLS negotiation? Do your other POP accounts secure the connection?
I would recommend reviewing your device documentation or contacting their support. Manually configuring outbound rules is typically much more involved than inbound rules.
You can also try reviewing the MiaB logs. Dovecot logs to /var/log/mail.log.
Is it just the TLS negotiation?
Don’t know but none of the other POP accounts initiate a connection back to me.
Do your other POP accounts secure the connection?
All of the other POP accounts are setup the same way, using the same ports.
I would recommend reviewing your device documentation or contacting their support
Already posted on their forum. Waiting for someone to chime in.
The log entries don’t show a connection from the Mail-in-a-Box server. The low port number on the Mail-in-a-Box side and the random high port number on the local side tells you that it was a connection from the local host to the Mail-in-a-Box, and since src is the Mail-in-a-Box side this log entry is for a reply packet.
Apparently tcpflags="RST" is (sometimes) the “connection refused” message. (I Googled it just now.) So the most likely thing is that the IMAP server isn’t running on the Mail-in-a-Box (or a firewall beyond your gateway is intercepting the connection and replying as if the IMAP server isn’t running).
Did you check the Mail-in-a-Box status checks to make sure everything is green?
Everything checks out as OK with no red text on the MiaB status-check page. I haven’t set up DNSEC, yet so it has a “?”.
You pointed out the key (tcpflags=“RST”) factor. After researching those terms, I found a simple explanation from a VERY knowledgeable source:
“…sometimes the UTM decides that a connection is finished before the other server decides it’s done - that’s why you’re seeing ACK and ACK RST packets dropped. Neither is really doing anything wrong here - it’s just meaningless noise that you should ignore.”
I guess I will create a firewall rule, on the UTM, just for the purpose of keeping the firewall log from being cluttered with these entries. It still would be interesting to find out why I get these dropped packets only from the MiaB server but figuring that out is beyond my knowledge level of connection tracking.
Noise on the other side (MiaB) consists of a lot of log entries in /var/log/mail.log from dovecot and I think even postfix maintaining TLS sessions. Maybe for some reason your gateway doesn’t think these are valid?
I don’t see any “red flags” in/var/log/mail.log. Below is an excerpt taken when I check email, which is also when I get the dropped RST packets in the UTM’s firewall log:
Jun 26 11:18:24 mail postfix/anvil[20208]: statistics: max cache size 5 at Jun 26 11:15:03
Jun 26 11:18:26 pop3-login: Info: Login: user=<<my email address>>, method=PLAIN, rip=<my gateway's public IP>, lip=<MIAB server's public IP>, mpid=20752, TLS, session=<HBSHxKzFodwy4FqB>
Jun 26 11:18:26 pop3(<my email address>): Info: Disconnected: Logged out top=0/0, retr=0/0, del=0/24, size=91187
Jun 26 11:18:27 imap-login: Info: Login: user=<<my email address>>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=20754, TLS, session=<qUfcxKzFwMJ/AAAB>
Jun 26 11:18:27 imap(<my email address>): Info: Logged out in=670 out=3171
Jun 26 11:18:56 imap-login: Info: Login: user=<<my email address>>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=20756, TLS, session=<2v5YxqzFhsJ/AAAB>
Jun 26 11:18:56 imap(<my email address>): Info: Logged out in=670 out=3171
Jun 26 11:19:25 imap-login: Info: Login: user=<<my email address>>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=20758, TLS, session=<14AVyKzFxWJ/AAAB>
Jun 26 11:19:25 imap(<my email address>): Info: Logged out in=670 out=3171
Jun 26 11:19:54 imap-login: Info: Login: user=<<my email address>>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=20765, TLS, session=<okXDyazFesJ/AAAB>
Jun 26 11:19:54 imap(<my email address>): Info: Logged out in=670 out=3179
Doing some reading it looks as if this is to do with the SSL connection not closing down cleanly. I’d be wary of filtering out any RST’s using the firewall as you could potentially be leaving a hanging connection on the server side.
The firewall rule that I created doesn’t block anything that the firewall is not already dropping. All that extra rule accomplishes is not logging the already dropped MiaB RST packets in an effort to keep my firewall log from being cluttered with useless info.
When a FIN or RST is seen, the connection tracking system will close down the session. As a result, any packet that comes across the connection tracking system from the connection that was recently terminated, will be Default Dropped. This explains why the responses sent to these packets are dropped. The packets can be dropped as the intended recipient won’t need them and they are not transmitting any data.
“TCP RST packet is the remote side telling you that the connection on which the previous TCP packet is sent is no longer valid, maybe the connection has closed, maybe the port is not open. Since the connection is not valid any more, there is no need to reply with an ACK”
“The connection tracker drops a connection as soon as a FIN or RST is received in one direction. Then the confirmation reply is dropped because there is no connection being tracked. So your firewall drops are noise that I have learned to ignore.”
Those RST packets are being dropped out of the INPUT chain. The UTM has a stateful firewall and the connection has already ended. The UTM’s connection tracker is no longer tracking the connection so it has no idea where to send a response packet and were MiaB to receive the packet, it likely would have no idea what to do with the packet.
Additional info: TCP reset attack - Wikipedia
So it seems to me that an extra, unneeded RST is being transmitted maybe because one of the MiaB app packages is expecting an unneeded verification that the connection has been closed. Keep in mind that MiaB seems to be working perfectly fine, otherwise. I also have dozens of POP3, IMAP and ActiveSync accounts on other external servers that I control and I have many accounts with third-party email service providers and I don’t get dropped RST packets from any of them.