Re: IMAPS and/or openssl problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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> 993
>>>> I 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.

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux