0

I'm running VMware Workstation 9.0.2 on Windows 7 Professional with a CentOS 6.4 guest using the bridged networking. The LAN that the host is running on is 192.168.123.*, the host is static IP 192.168.123.2 and the guest has static IP 192.168.123.70.

I can ping and ssh from the host to the CentOS guest, but telnet and http both fail to connect. I can telnet and http from the guest to the guest using the 192.168.123.70 address, so the ports on the guest are definitely open and being listened upon.

The firewall has been turned off on the guest and there are no messages in the log when telnet fails. (The Windows firewall doesn't restrict outgoing connections.)

I can't think of anything that could allow ssh but not allow telnet. (I can connect from the host to the guest when I use telnet 192.168.123.70 22, but telnet 192.168.123.70 23 doesn't connect).

Other data:

Here's the output from /sbin/ifconfig -a from the guest:

eth0      Link encap:Ethernet  HWaddr 00:0C:29:1F:A5:E3  
          inet addr:192.168.123.70  Bcast:192.168.123.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:589132 errors:0 dropped:0 overruns:0 frame:0
          TX packets:292849 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:864633856 (824.5 MiB)  TX bytes:19627138 (18.7 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:275 errors:0 dropped:0 overruns:0 frame:0
          TX packets:275 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:121617 (118.7 KiB)  TX bytes:121617 (118.7 KiB)

Here's the output from netstat -l from the guest:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
tcp        0      0 *:8008                      *:*                         LISTEN      
tcp        0      0 *:8010                      *:*                         LISTEN      
tcp        0      0 *:8011                      *:*                         LISTEN      
tcp        0      0 *:http                      *:*                         LISTEN      
tcp        0      0 *:intu-ec-svcdisc           *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 election-t1,:ipp            *:*                         LISTEN      
tcp        0      0 *:https                     *:*                         LISTEN      
tcp        0      0 *:8030                      *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 *:telnet                    *:*                         LISTEN      
udp        0      0 *:ipp                       *:*                                     
udp        0      0 192.168.123.70:ntp          *:*                                     
udp        0      0 election-t1,:ntp            *:*                                     
udp        0      0 *:ntp                       *:*                                     
udp        0      0 *:ntp                       *:*

Any suggestions as to possible cause of what further information to look for would be greatly appreciated. I don't have a mental model that could explain this behavior.

Addendum: Restarted xinetd service on guest and stopped Windows Firewall on host - no effect at all.

Addendum 2: Output of sudo iptables -L -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Improve this question
  • Please post the output of sudo iptables -L -n when executed on the guest. – user Jul 15 '13 at 18:35
  • done. Thanks. Not certain what the state NEW tcp dpt:22 means, but it does point to special behavior by SSH. Now investigating. – Tom West Jul 15 '13 at 19:00
1

It's a little hard to tell (I should have said post the output of sudo iptables -L -n -v instead, so we could see the interface specifier; it's probably lo on the rule that appears to accept everything), but it looks like the firewall on the guest is blocking the connection since the only apparently relevant accept you have is for state NEW tcp dpt:22 (allowing new SSH connections; existing TCP connections are handled by the first rule).

Try executing sudo iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT and retrying the connection from the host; that should allow you to connect over HTTP. (The 5 puts it immediately before the REJECT rule) If that works, you'll need to look into how to properly allow connections to the host on the telnet (23/tcp), http (80/tcp) and possibly https (443/tcp) ports. (There is probably a CentOS way, but I am not familiar with CentOS specifically.)

However, unless this is strictly for testing (and even then I'd have my doubts), reconsider your decision to allow telnet access. Telnet is unencrypted and totally insecure; anyone with a packet sniffer anywhere along the path will be able to monitor all traffic, including plain-text usernames and passwords. Telnet dates all the way back to 1969, when the Internet was a very different place. Consider only allowing SSH instead, unless you have some specific application which requires telnet specifically.

I also notice that you have a REJECT rule at the end of the INPUT chain, followed by an ACCEPT policy. Unless you have some specific reason for setting it up that way, the normal way to set up a default reject action is to simply set the policy on the chain (sudo iptables -P INPUT REJECT should do it); then you don't need an explicit reject rule.

Improve this answer
  • The explicit reject is there to use "reject-with icmp-host-prohibited". And yes, the ACCEPT all will be only for lo interface. This is a standard setup for iptables in CentOS. It will accept incoming SSH, and all outgoing connections. – Squeezy Jul 15 '13 at 19:17
  • @Squeezy Yes, hence "unless you have some specific reason for setting it up that way". Many times (though not always) a simple reject policy is enough. – user Jul 15 '13 at 19:19
  • As this is the iptables default in CentOS I doubt he has set up anything yet :) – Squeezy Jul 15 '13 at 19:20
  • Thank you. Despite what I thought was turning off iptables (/etc/init.d/iptables save followed by /etc/init.d/iptables save), iptables was apparently still active. As for using telnet, this is a small internal test server on a local LAN. The program answering is not actually a shell, but a separate program emulating a telnet server for connection, but gives no access to the system. Our externally facing production servers are connected behind a full iptables firewall that only allow specific hosts to attach by ip. Many, many thanks for this. – Tom West Jul 15 '13 at 19:30
0

If firewall blocking is suspected, you can try some of the VMware tests on IsMyPortBlocked

You can also enter your own list of TCP and UDP ports.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.