I'm trying to access my IMAPS (dovecot) server on my laptop while on holiday. But when I run kmail I get the message "Could not connect to host <myserver>". Both server and laptop are running Fedora 7 + KDE.
I suspect the problem lies in my openssl setup, as when I run openssl s_client -ssl2 -crlf -host <myserver> -port 993 I get no response - the program just waits until I press ctrl-C.
As is probably obvious, I am fairly ignorant about all this. I can access my server with ssh, and so can change anything there, except that I am unable to access the ADSL modem, where I have opened peepholes for ssh, http and imaps (port 993).
(I cannot access the modem because when I run firefox on the server it does not open a window on my laptop - perhaps an X-permissions issue?)
Any advice or suggestions gratefully received.
On Thu, 2007-08-30 at 14:07 +0200, Timothy Murphy wrote:
I'm trying to access my IMAPS (dovecot) server on my laptop while on holiday. But when I run kmail I get the message "Could not connect to host <myserver>". Both server and laptop are running Fedora 7 + KDE.
I suspect the problem lies in my openssl setup, as when I run openssl s_client -ssl2 -crlf -host <myserver> -port 993 I get no response - the program just waits until I press ctrl-C.
As is probably obvious, I am fairly ignorant about all this. I can access my server with ssh, and so can change anything there, except that I am unable to access the ADSL modem, where I have opened peepholes for ssh, http and imaps (port 993).
(I cannot access the modem because when I run firefox on the server it does not open a window on my laptop - perhaps an X-permissions issue?)
Any advice or suggestions gratefully received.
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
May be a dumb questions, but ... port 993 is open on the server (it's in iptables, for example)? Can you telnet to port 993 on the server and get some kind of response?
-- Mark C. Allman, PMP -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263
BusinessMsg -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution.
Mark C. Allman wrote:
I'm trying to access my IMAPS (dovecot) server on my laptop while on holiday. But when I run kmail I get the message "Could not connect to host <myserver>". Both server and laptop are running Fedora 7 + KDE.
I suspect the problem lies in my openssl setup, as when I run openssl s_client -ssl2 -crlf -host <myserver> -port 993 I get no response - the program just waits until I press ctrl-C.
...
Any advice or suggestions gratefully received.
May be a dumb questions, but ... port 993 is open on the server (it's in iptables, for example)? Can you telnet to port 993 on the server and get some kind of response?
Thanks for your response.
Yes, I am running shorewall, and have IMAPS/ACCEPT net $FW in /etc/shorewall/rules .
When I run telnet <myserver> 993 I just get Trying <server IP address> and nothing further, until I type ctrl-C. Maybe it would time out if I left it long enough.
(With almost any other port, I get an immediate "Connection refused".)
On Thu, 2007-08-30 at 18:28 +0200, Timothy Murphy wrote:
Mark C. Allman wrote:
I'm trying to access my IMAPS (dovecot) server on my laptop while on holiday. But when I run kmail I get the message "Could not connect to host <myserver>". Both server and laptop are running Fedora 7 + KDE.
I suspect the problem lies in my openssl setup, as when I run openssl s_client -ssl2 -crlf -host <myserver> -port 993 I get no response - the program just waits until I press ctrl-C.
...
Any advice or suggestions gratefully received.
May be a dumb questions, but ... port 993 is open on the server (it's in iptables, for example)? Can you telnet to port 993 on the server and get some kind of response?
Thanks for your response.
Yes, I am running shorewall, and have IMAPS/ACCEPT net $FW in /etc/shorewall/rules .
When I run telnet <myserver> 993 I just get Trying <server IP address> and nothing further, until I type ctrl-C. Maybe it would time out if I left it long enough.
(With almost any other port, I get an immediate "Connection refused".)
-- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the firewall, but you could just about rule it out by shutting down the firewall for a minute, test (e.g., telnet), and then starting it again.
-- Mark C. Allman, PMP -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263
BusinessMsg -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution.
Somebody in the thread at some point said:
telnet <myserver> 993I just get Trying <server IP address> and nothing further, until I type ctrl-C.
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the
No, he doesn't even get a tcp connection established. If I telnet to my IMAP server I see
telnet 192.168.0.xx 993 Trying 192.168.0.xx... Connected to 192.168.0.xx. Escape character is '^]'.
I would first confirm that something is still listening on your external network interface on 993.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
-Andy
On Thu, 2007-08-30 at 21:09 +0100, Andy Green wrote:
Somebody in the thread at some point said:
telnet <myserver> 993I just get Trying <server IP address> and nothing further, until I type ctrl-C.
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the
No, he doesn't even get a tcp connection established. If I telnet to my IMAP server I see
telnet 192.168.0.xx 993 Trying 192.168.0.xx... Connected to 192.168.0.xx. Escape character is '^]'.
I would first confirm that something is still listening on your external network interface on 993.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
-Andy
I'm thinking that you get the "Connected to" message from telnet when the initial connection completes. You get a "Connection refused" when the firewall blocks the connection. So telnet is trying, and trying, and trying to connect. Maybe while trying there's an error occurring that's being logged to /var/log/messages. You are correct that the connection is never completely established, but it doesn't appear to be blocked either.
Another (trivial) suggestion: use netstat to be sure there's something listening on port 993. Is it "0.0.0.0:993" (all interfaces) or "127.0.0.1:993" (just the loopback)?
-- Mark C. Allman, PMP -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263
BusinessMsg -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution.
Mark C. Allman wrote:
I'm thinking that you get the "Connected to" message from telnet when the initial connection completes. You get a "Connection refused" when the firewall blocks the connection. So telnet is trying, and trying, and trying to connect. Maybe while trying there's an error occurring that's being logged to /var/log/messages. You are correct that the connection is never completely established, but it doesn't appear to be blocked either.
This sounds like imaps is not being launched. This could be because inetd is not running, or the imaps service in not enabled.
Mikkel
Andy Green wrote:
Somebody in the thread at some point said:
telnet <myserver> 993I just get Trying <server IP address> and nothing further, until I type ctrl-C.
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the
No, he doesn't even get a tcp connection established. If I telnet to my IMAP server I see
telnet 192.168.0.xx 993 Trying 192.168.0.xx... Connected to 192.168.0.xx. Escape character is '^]'.
I would first confirm that something is still listening on your external network interface on 993.
Thanks for all the responses.
nmap seems to show that port 993 is open: ===================================== [tim@martha ~]$ nmap 86.43.71.228
Starting Nmap 4.20 ( http://insecure.org ) at 2007-08-31 02:13 CEST Interesting ports on 86.43.71.228: Not shown: 1688 closed ports PORT STATE SERVICE 80/tcp open http 135/tcp filtered msrpc 139/tcp filtered netbios-ssn 445/tcp filtered microsoft-ds 593/tcp filtered http-rpc-epmap 993/tcp filtered imaps 1720/tcp filtered H.323/Q.931 2001/tcp open dc 5190/tcp open aol
Nmap finished: 1 IP address (1 host up) scanned in 20.467 seconds =====================================
But "netstat -anp --tcp" does not show anything listening on 993 ===================================== [tim@martha ~]$ sudo netstat -anp --tcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1745/nasd tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 1637/hpiod tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1654/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1714/sendmail: acce tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 1642/python tcp 0 0 0.0.0.0:33215 0.0.0.0:* LISTEN 1443/rpc.statd tcp 0 0 192.168.1.149:34676 86.43.71.228:2001 ESTABLISHED 3298/ssh tcp 0 0 :::901 :::* LISTEN 1680/xinetd tcp 0 0 :::111 :::* LISTEN 1422/rpcbind tcp 0 0 :::22 :::* LISTEN 1668/sshd tcp 0 0 :::631 :::* LISTEN 1654/cupsd =====================================
I can telnet 993 on my server without problem: ===================================== [tim@alfred ~]$ telnet localhost 993 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. ^] telnet> quit Connection closed. =====================================
And "iptables -L" seems to allow this connection: ===================================== ... Chain net2fw (1 references) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:appserv-http ACCEPT udp -- anywhere anywhere udp dpt:appserv-http ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:imaps Drop 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Shorewall:net2fw:DROP:' DROP 0 -- anywhere anywhere ... =====================================
So my best guess is that there is something wrong with my dovecot configuration. I "yum remove"d and "yum install"ed dovecot (and re-edited dovecot.conf), but that didn't seem to make any difference.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
I'll try these tomorrow. Thanks very much for your help anyway.
Timothy Murphy wrote:
Andy Green wrote:
Somebody in the thread at some point said:
telnet <myserver> 993I just get Trying <server IP address> and nothing further, until I type ctrl-C.
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the
No, he doesn't even get a tcp connection established. If I telnet to my IMAP server I see
telnet 192.168.0.xx 993 Trying 192.168.0.xx... Connected to 192.168.0.xx. Escape character is '^]'.
I would first confirm that something is still listening on your external network interface on 993.
Thanks for all the responses.
nmap seems to show that port 993 is open:
[tim@martha ~]$ nmap 86.43.71.228
Starting Nmap 4.20 ( http://insecure.org ) at 2007-08-31 02:13 CEST Interesting ports on 86.43.71.228: Not shown: 1688 closed ports PORT STATE SERVICE 80/tcp open http 135/tcp filtered msrpc 139/tcp filtered netbios-ssn 445/tcp filtered microsoft-ds 593/tcp filtered http-rpc-epmap 993/tcp filtered imaps 1720/tcp filtered H.323/Q.931 2001/tcp open dc 5190/tcp open aol
Except that if you read the man page for nmap you find....
Filtered means that a firewall, filter, or other network obstacle is covering the port and preventing nmap from determining whether the port is open.
And
[egreshko@misty ~]$ telnet 86.43.71.228 993 Trying 86.43.71.228...
Times out....
Nmap finished: 1 IP address (1 host up) scanned in 20.467 seconds
But "netstat -anp --tcp" does not show anything listening on 993
[tim@martha ~]$ sudo netstat -anp --tcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1745/nasd tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 1637/hpiod tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1654/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1714/sendmail: acce tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 1642/python tcp 0 0 0.0.0.0:33215 0.0.0.0:* LISTEN 1443/rpc.statd tcp 0 0 192.168.1.149:34676 86.43.71.228:2001 ESTABLISHED 3298/ssh tcp 0 0 :::901 :::* LISTEN 1680/xinetd tcp 0 0 :::111 :::* LISTEN 1422/rpcbind tcp 0 0 :::22 :::* LISTEN 1668/sshd tcp 0 0 :::631 :::* LISTEN 1654/cupsd =====================================
I can telnet 993 on my server without problem:
[tim@alfred ~]$ telnet localhost 993 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. ^] telnet> quit Connection closed. =====================================
And "iptables -L" seems to allow this connection:
... Chain net2fw (1 references) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:appserv-http ACCEPT udp -- anywhere anywhere udp dpt:appserv-http ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:imaps Drop 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Shorewall:net2fw:DROP:' DROP 0 -- anywhere anywhere ... =====================================
So my best guess is that there is something wrong with my dovecot configuration. I "yum remove"d and "yum install"ed dovecot (and re-edited dovecot.conf), but that didn't seem to make any difference.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
I'll try these tomorrow. Thanks very much for your help anyway.
On Fri, 2007-08-31 at 10:18 +0800, Ed Greshko wrote:
Timothy Murphy wrote:
Andy Green wrote:
Somebody in the thread at some point said:
telnet <myserver> 993I just get Trying <server IP address> and nothing further, until I type ctrl-C.
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the
No, he doesn't even get a tcp connection established. If I telnet to my IMAP server I see
telnet 192.168.0.xx 993 Trying 192.168.0.xx... Connected to 192.168.0.xx. Escape character is '^]'.
I would first confirm that something is still listening on your external network interface on 993.
Thanks for all the responses.
nmap seems to show that port 993 is open:
[tim@martha ~]$ nmap 86.43.71.228
Starting Nmap 4.20 ( http://insecure.org ) at 2007-08-31 02:13 CEST Interesting ports on 86.43.71.228: Not shown: 1688 closed ports PORT STATE SERVICE 80/tcp open http 135/tcp filtered msrpc 139/tcp filtered netbios-ssn 445/tcp filtered microsoft-ds 593/tcp filtered http-rpc-epmap 993/tcp filtered imaps 1720/tcp filtered H.323/Q.931 2001/tcp open dc 5190/tcp open aol
Except that if you read the man page for nmap you find....
Filtered means that a firewall, filter, or other network obstacle is covering the port and preventing nmap from determining whether the port is open.
And
[egreshko@misty ~]$ telnet 86.43.71.228 993 Trying 86.43.71.228...
Times out....
Nmap finished: 1 IP address (1 host up) scanned in 20.467 seconds
But "netstat -anp --tcp" does not show anything listening on 993
[tim@martha ~]$ sudo netstat -anp --tcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1745/nasd tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 1637/hpiod tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1654/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1714/sendmail: acce tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 1642/python tcp 0 0 0.0.0.0:33215 0.0.0.0:* LISTEN 1443/rpc.statd tcp 0 0 192.168.1.149:34676 86.43.71.228:2001 ESTABLISHED 3298/ssh tcp 0 0 :::901 :::* LISTEN 1680/xinetd tcp 0 0 :::111 :::* LISTEN 1422/rpcbind tcp 0 0 :::22 :::* LISTEN 1668/sshd tcp 0 0 :::631 :::* LISTEN 1654/cupsd =====================================
I can telnet 993 on my server without problem:
[tim@alfred ~]$ telnet localhost 993 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. ^] telnet> quit Connection closed. =====================================
And "iptables -L" seems to allow this connection:
... Chain net2fw (1 references) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:appserv-http ACCEPT udp -- anywhere anywhere udp dpt:appserv-http ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:imaps Drop 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Shorewall:net2fw:DROP:' DROP 0 -- anywhere anywhere ... =====================================
So my best guess is that there is something wrong with my dovecot configuration. I "yum remove"d and "yum install"ed dovecot (and re-edited dovecot.conf), but that didn't seem to make any difference.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
I'll try these tomorrow. Thanks very much for your help anyway.
-- First Law of Bicycling: No matter which way you ride, it's uphill and against the wind.
I had a problem with my app/web server listening on "::::80" awhile back. I'd try to connect (telnet, browser, etc.) and it'd just sit there. I switched to listen on "0.0.0.0:80" and it all worked like a charm. I'm terribly ignorant on IPv6 so I can't speak to what the root problem was, but the work-around did the trick.
-- Mark C. Allman, PMP -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263
BusinessMsg -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution.
It has been written:
Except that if you read the man page for nmap you find....
Filtered means that a firewall, filter, or other network obstacle is covering the port and preventing nmap from determining whether the port is open.
And
[egreshko@misty ~]$ telnet 86.43.71.228 993 Trying 86.43.71.228...
Times out....
Nmap finished: 1 IP address (1 host up) scanned in 20.467 seconds
But "netstat -anp --tcp" does not show anything listening on 993
I forgot to mention....that you should see....
[root@f7 ~]# netstat -nap | grep 993 tcp 0 0 :::993 :::* LISTEN 3318/dovecot
Or something to that effect.
But, since you said that telnet to port 993 on localhost works it is confusing.
You don't happen to have an DSL router with an embedded firewall giving you grief do you?
For a test, you can always disable your firewall and check again. The port should show as "open" and not "filtered".
===================================== [tim@martha ~]$ sudo netstat -anp --tcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1745/nasd tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 1637/hpiod tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1654/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1714/sendmail: acce tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 1642/python tcp 0 0 0.0.0.0:33215 0.0.0.0:* LISTEN 1443/rpc.statd tcp 0 0 192.168.1.149:34676 86.43.71.228:2001 ESTABLISHED 3298/ssh tcp 0 0 :::901 :::* LISTEN 1680/xinetd tcp 0 0 :::111 :::* LISTEN 1422/rpcbind tcp 0 0 :::22 :::* LISTEN 1668/sshd tcp 0 0 :::631 :::* LISTEN 1654/cupsd =====================================
I can telnet 993 on my server without problem:
[tim@alfred ~]$ telnet localhost 993 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. ^] telnet> quit Connection closed. =====================================
And "iptables -L" seems to allow this connection:
... Chain net2fw (1 references) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:appserv-http ACCEPT udp -- anywhere anywhere udp dpt:appserv-http ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:imaps Drop 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Shorewall:net2fw:DROP:' DROP 0 -- anywhere anywhere ... =====================================
So my best guess is that there is something wrong with my dovecot configuration. I "yum remove"d and "yum install"ed dovecot (and re-edited dovecot.conf), but that didn't seem to make any difference.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
I'll try these tomorrow. Thanks very much for your help anyway.
-- First Law of Bicycling: No matter which way you ride, it's uphill and against the wind.
I had a problem with my app/web server listening on "::::80" awhile back. I'd try to connect (telnet, browser, etc.) and it'd just sit there. I switched to listen on "0.0.0.0:80" and it all worked like a charm. I'm terribly ignorant on IPv6 so I can't speak to what the root problem was, but the work-around did the trick.
-- *Mark C. Allman, PMP* -- Allman Professional Consulting, Inc. -- www.allmanpc.com http://www.allmanpc.com, 617-947-4263
*BusinessMsg* -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution.
Somebody in the thread at some point said:
So my best guess is that there is something wrong with my dovecot configuration. I "yum remove"d and "yum install"ed dovecot (and re-edited dovecot.conf), but that didn't seem to make any difference.
Anything in /var/log/maillog when you start Dovecot? /var/log/messages?
The ssh tunnel will change the landscape for networking issues because it will seem to Dovecot you are coming from localhost. But if Dovecot is unhappy or dead it won't change that.
-Andy
Timothy Murphy wrote:
Andy Green wrote:
Somebody in the thread at some point said:
telnet <myserver> 993I just get Trying <server IP address> and nothing further, until I type ctrl-C.
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the
No, he doesn't even get a tcp connection established. If I telnet to my IMAP server I see
telnet 192.168.0.xx 993 Trying 192.168.0.xx... Connected to 192.168.0.xx. Escape character is '^]'.
I would first confirm that something is still listening on your external network interface on 993.
Thanks for all the responses.
nmap seems to show that port 993 is open:
[tim@martha ~]$ nmap 86.43.71.228
Starting Nmap 4.20 ( http://insecure.org ) at 2007-08-31 02:13 CEST Interesting ports on 86.43.71.228: Not shown: 1688 closed ports PORT STATE SERVICE 80/tcp open http 135/tcp filtered msrpc 139/tcp filtered netbios-ssn 445/tcp filtered microsoft-ds 593/tcp filtered http-rpc-epmap 993/tcp filtered imaps 1720/tcp filtered H.323/Q.931 2001/tcp open dc 5190/tcp open aol
Nmap finished: 1 IP address (1 host up) scanned in 20.467 seconds
But "netstat -anp --tcp" does not show anything listening on 993
[tim@martha ~]$ sudo netstat -anp --tcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1745/nasd tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 1637/hpiod tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1654/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1714/sendmail: acce tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1878/smbd tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 1642/python tcp 0 0 0.0.0.0:33215 0.0.0.0:* LISTEN 1443/rpc.statd tcp 0 0 192.168.1.149:34676 86.43.71.228:2001 ESTABLISHED 3298/ssh tcp 0 0 :::901 :::* LISTEN 1680/xinetd tcp 0 0 :::111 :::* LISTEN 1422/rpcbind tcp 0 0 :::22 :::* LISTEN 1668/sshd tcp 0 0 :::631 :::* LISTEN 1654/cupsd =====================================
I can telnet 993 on my server without problem:
[tim@alfred ~]$ telnet localhost 993 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. ^] telnet> quit Connection closed. =====================================
And "iptables -L" seems to allow this connection:
... Chain net2fw (1 references) target prot opt source destination ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:appserv-http ACCEPT udp -- anywhere anywhere udp dpt:appserv-http ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:imaps Drop 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Shorewall:net2fw:DROP:' DROP 0 -- anywhere anywhere ... =====================================
So my best guess is that there is something wrong with my dovecot configuration. I "yum remove"d and "yum install"ed dovecot (and re-edited dovecot.conf), but that didn't seem to make any difference.
Why not tcpdump it over your ssh session to the server while you try to connect and see what you can see.
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
I'll try these tomorrow. Thanks very much for your help anyway.
Tim,
Is fred the server and martha the remote machine? If so, the netstat command should be run on fred. I'd also check /etc/hosts.allow and /etc/hosts.deny.
Bob...
Bob Chiodini wrote:
Is fred the server and martha the remote machine? If so, the netstat command should be run on fred. I'd also check /etc/hosts.allow and /etc/hosts.deny.
Yes, thanks. I think I was a little confused on that point. alfred is my server, in Ireland. martha is my laptop, in Italy.
When I run netstat on alfred, I do indeed see dovecot listed: ===================================== [root@alfred shorewall]# netstat -anp --tcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 3160/nasd tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 21841/dovecot ... =====================================
/etc/hosts.allow and /etc/hosts.deny are both empty, on alfred and martha .
Stopping the firewall on alfred (with "shorewall clear") does not seem to alter the situation in any way.
So it seems to me my problem probably lies with my dovecot settings.
[Just to recall: when I "sudo telnet <alfred IP> 993" on my laptop I don't get "Connection refused"; I get "Trying <IP address?..." and nothing more.]
As ever, any and all suggestions gratefully received.
Timothy Murphy wrote:
Another more exotic workaround would be, on your local machine
ssh root@myserver -N -L993:localhost:993
while this runs, 993 (the first number) on your local client box will magically be an encrypted wormhole to port 993 on myserver. Try running that in one terminal session, and temporarily alter kmail to go look at localhost for IMAP instead of myserver.
I tried this, but I don't think I was allowed to do it: ------------------------------------ [tim@martha ~]$ sudo ssh root@www.gayleard.com -p2001 -N -L993:localhost:993 The authenticity of host '[www.gayleard.com]:2001 ([86.43.71.228]:2001)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[www.gayleard.com]:2001,[86.43.71.228]:2001' (RSA) to the list of known hosts. root@www.gayleard.com's password: Permission denied, please try again. root@www.gayleard.com's password: ------------------------------------
However, I went ahead and changed the IMAPS server in kmail on my laptop to localhost; this gave the error "The server certificate failed the authenticity test (localhost)."
I wonder if I could have a problem with my dovecot certs? I'll re-create them and see if that is any better.
Somebody in the thread at some point said:
root@www.gayleard.com's password: Permission denied, please try again. root@www.gayleard.com's password:
Not allowed? Presumably your root password for "www.gayleard.com" was accepted if it was correct enough to ssh into that box normally? (yes yes, settle down you Australians in the back).
However, I went ahead and changed the IMAPS server in kmail on my laptop to localhost; this gave the error "The server certificate failed the authenticity test (localhost)."
I wonder if I could have a problem with my dovecot certs? I'll re-create them and see if that is any better.
If you told kmail previously to accept that cert from "server", then it could be quite right to complain when it finds the same cert apparently being delivered from "localhost" in this setup.
You should be able to okay it anyway and go on, at least that is what Thunderbird does.
-Andy
On Fri 31 Aug 2007, Andy Green wrote:
"The server certificate failed the authenticity test (localhost)."
I wonder if I could have a problem with my dovecot certs? I'll re-create them and see if that is any better.
If you told kmail previously to accept that cert from "server", then it could be quite right to complain when it finds the same cert apparently being delivered from "localhost" in this setup.
Thanks very much, Andy and all those who offered suggestions, most of which I tried.
In the end I found I already had the answer. I thought I did not get a window on my laptop when I ran firefox on my server; but I happened to leave it running while I went to the toilet, and found that after 8 minutes it did indeed come up on my laptop. So I was able to open a pinhole to port 993 on my modem in Ireland. This took about an hour, as each new page took several minutes to come up ...
Fortunately life here in Italy proceeds at a sensible slow pace, so waiting an hour was par for the course. (One has to wait longer to get ciabatta in the baker, while listening to the saga of the previous customer's cousin's wedding ...)
Mark C. Allman wrote:
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the firewall, but you could just about rule it out by shutting down the firewall for a minute, test (e.g., telnet), and then starting it again.
Thanks for your response.
I never seem to get any messages about dovecot in /var/log/messages . I opened a log-file /var/log/dovecot to get dovecot debug messages, but this doesn't get much either. Just a message when dovecot starts of finishes.
I tried closing the firewall with "shorewall clear" but this didn't have any effect.
On Fri, 2007-08-31 at 15:06 +0200, Timothy Murphy wrote:
Mark C. Allman wrote:
Check /var/log/messages to see if anything is logged. The behavior of telnet sounds like the behavior of openssl. It's probably not the firewall, but you could just about rule it out by shutting down the firewall for a minute, test (e.g., telnet), and then starting it again.
Thanks for your response.
I never seem to get any messages about dovecot in /var/log/messages . I opened a log-file /var/log/dovecot to get dovecot debug messages, but this doesn't get much either. Just a message when dovecot starts of finishes.
I tried closing the firewall with "shorewall clear" but this didn't have any effect.
Did you verify with iptables -L that things were really opened up?
Andy
-
Andrew Kelly -
Andy Green -
Bob Chiodini -
Ed Greshko -
Mark C. Allman -
Mikkel -
Timothy Murphy -
Timothy Murphy