Currently I am trying to trouble shoot an e-mail server that will allow users to send e-mail, but not log in to the server (POP3) or receive e-mail using their Outlook clients. Previously this was doable, but moving the server to it's current location broke it. For obvious reasons, I suspect it's the firewall causing issues.
Firstly, here is what the handshake (or attempt at) looked like before I made any changes to the firewall:
mail-server: 192.168.25.26 client: 192.168.25.50
Source | Destination | PROTO | INFO
192.168.25.50 192.168.25.26 TCP 50861 > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26 192.168.25.50 TCP pop3 > 58601 [RST, ACK] seq=1 win=1 len=0
192.168.25.50 192.168.25.26 TCP [TCP Retransmission] 58061 > pop3 [Syn] etc....
and the [rst, ack], [tcp retransmission] dance happens once more before failing.
The rules for the firewall (Cisco) concerning 192.168.25.26 and pop3 are as follows:
inside:
source | destination | service
any 192.168.25.0/24 tcp/pop3
192.168.25.0/24 any tcp/smtp
208.105.121.196
outside:
source | destination | service
any 192.168.25.26 tcp/pop3
any tcp/smtp
To me, that looks fine.
To be certain, on the email server (Zentyal) I ran the following commands:
(IP tables was HEAVILY configured. I suspect the issue lies here. Is there any way to allow all traffic, just for testing's sake?)
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
However, there's still no outlook connectability. At this point, on the email server I ran the command:
telnet 127.0.0.1 110
and was able to log in to the mail server. From a client inside the network, I ran the same command and was told the "connection failed".
After these changes, when I attempt to "test the settings" in Outlook, here's what the handshake looks like. I noticed something peculiar.
Source | Destination | PROTO | INFO
192.168.25.50 192.168.25.26 TCP apollo-status > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26 192.168.25.50 TCP pop3 > apollo-status [RST, ACK] seq=1 win=1 len=0
192.168.25.50 192.168.25.26 TCP [TCP Retransmission] apollo-status > pop3 [Syn] etc....
and it does it twice more, like the last time. In the INFO pane, I now see apollo-status instead of a port number. The next two times I ran it, I saw npep_messaging and synapse, respectively. I suspect these are random ports chosen by dovecot, because in dovecot.config I changed the default listener to an asterisk "*" from the port previously specified, which seemed to be an arbitrary port in the 4,000's and had no rules in the firewall.
Just to confirm, it seems the port it uses each time is changing based on the (recommended) configuration. On the loopback interface port 110 clearly has a listener attatched to it, but from another computer, it appears to be closed.
Any help at all is appreciated. I've racked my brain with this, and I'm hoping the serverfault community will have some novel ideas.
Thank you!
