1

Simply speaking, the forwarded port 45922 is accessible on the host via 127.0.0.1:45922, but not accessible on the host itself via its public IP plus port number 45922. Details are as follows.

Host OS: Ubuntu 14.04.2 LTS
Guest OS: CentOS 6.6 (Final)
Virtual Machine: VMware Player 7

VM is started in the terminal using the following command:

vmrun -T player start vmware/CentOS/CentOS.vmx nogui

The host has a public IP address which is 128.x.x.221
The guest has two network adapters, one is bridged and has a public IP address which is 128.x.x.219, the other works in NAT mode and has a local IP address which is 192.168.106.129.

Content of host configuration file /etc/vmware/vmnet8/nat/nat.conf

45922 = 192.168.106.129:22
45911 = 192.168.106.129:5911

The first port forwarding is for SSH, the second for VNC. Basically they are suffering from the same problem so I'd like to put them together here.

Observed problems:

  1. On the CentOS guest:
    ssh 127.0.0.1 working
    ssh 192.168.106.129 working

  2. On the Ubuntu host:
    ssh 192.168.106.129 working
    ssh -p 45922 127.0.0.1 working
    ssh -p 45922 128.x.x.221 NOT working

  3. From a random public machine:
    ssh -p 45922 128.x.x.221 NOT working

However, at the same time, the bridged network works fine. From a random public machine:
ssh 128.x.x.219 working

Neither the host or the guest has firewall enabled. iptables -L returns empty lists.

It doesn't seem to be a problem of gateway firewall, since the host has another port 45940 open, and is accessible from a random public machine.

Additional information

Running netstat on the host:

$ netstat -ano | grep 459 
tcp        0      0 0.0.0.0:45911           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:45922           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:45940           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp6       0      0 :::45940                :::*                    LISTEN      off (0.00/0/0)
udp        0      0 0.0.0.0:45932           0.0.0.0:*                           off (0.00/0/0)

Running tcpdump port 45922 on the host doesn't catch any packet when I do ssh -p 45922 128.x.x.221 on the host itself.

Running ssh -vvv -p 45922 128.x.x.221 on a random machine outputs this:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 128.x.x.221 [128.x.x.221] port 45922.
debug1: Connection established.
debug1: identity file /home/x/.ssh/id_rsa type -1
debug1: identity file /home/x/.ssh/id_rsa-cert type -1
debug1: identity file /home/x/.ssh/id_dsa type -1
debug1: identity file /home/x/.ssh/id_dsa-cert type -1
debug1: identity file /home/x/.ssh/id_ecdsa type -1
debug1: identity file /home/x/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/x/.ssh/id_ed25519 type -1
debug1: identity file /home/x/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
ssh_exchange_identification: read: Connection reset by peer

Running tcpdump port 45922 -vv on the host outputs the following info when I try to connect to the guest from a random machine on the public network:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:56:56.942537 IP (tos 0x0, ttl 60, id 64633, offset 0, flags [DF], proto TCP (6), length 60)
    vcv069158.x.x.x.44417 > dhcp-x221.x.x.x.45922: Flags [S], cksum 0x13ee (correct), seq 584972499, win 25820, options [mss 1291,sackOK,TS val 2545185 ecr 0,nop,wscale 7], length 0
12:56:56.942603 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44417: Flags [S.], cksum 0x7d30 (incorrect -> 0xfd9e), seq 2889461335, ack 584972500, win 28960, options [mss 1460,sackOK,TS val 1093302 ecr 2545185,nop,wscale 0], length 0
12:56:57.042734 IP (tos 0x0, ttl 60, id 64634, offset 0, flags [DF], proto TCP (6), length 52)
    vcv069158.x.x.x.44417 > dhcp-x221.x.x.x.45922: Flags [.], cksum 0x9c9f (correct), seq 1, ack 1, win 202, options [nop,nop,TS val 2545212 ecr 1093302], length 0
12:56:57.046954 IP (tos 0x0, ttl 60, id 64635, offset 0, flags [DF], proto TCP (6), length 93)
    vcv069158.x.x.x.44417 > dhcp-x221.x.x.x.45922: Flags [P.], cksum 0x7748 (correct), seq 1:42, ack 1, win 202, options [nop,nop,TS val 2545212 ecr 1093302], length 41
12:56:57.046973 IP (tos 0x0, ttl 64, id 151, offset 0, flags [DF], proto TCP (6), length 52)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44417: Flags [.], cksum 0x7d28 (incorrect -> 0x2c06), seq 1, ack 42, win 28960, options [nop,nop,TS val 1093328 ecr 2545212], length 0
12:57:01.371307 IP (tos 0x0, ttl 64, id 50327, offset 0, flags [DF], proto TCP (6), length 52)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44416: Flags [R.], cksum 0x7d28 (incorrect -> 0x58b6), seq 81219880, ack 929809342, win 28960, options [nop,nop,TS val 1094409 ecr 2542228], length 0
12:57:27.042892 IP (tos 0x0, ttl 64, id 152, offset 0, flags [DF], proto TCP (6), length 52)
    dhcp-x221.x.x.x.45922 > vcv069158.x.x.x.44417: Flags [R.], cksum 0x7d28 (incorrect -> 0x0eb7), seq 1, ack 42, win 28960, options [nop,nop,TS val 1100827 ecr 2545212], length 0
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

It seems that every packet that the host (221) sent has cksum incorrect. I have no idea why this happened...

Improve this question
3
  • "ssh -p 45922 128.x.x.221 NOT working" What specifically happens when you try? Does ssh print an error message? What does the error say?
    – Kenster
    Commented Apr 7, 2015 at 1:43
  • @Kenster Please see newly added details in problem spec.
    – bfrgzju
    Commented Apr 7, 2015 at 15:08
  • @Kenster If I don't use -vvv it outputs only ssh_exchange_identification: read: Connection reset by peer
    – bfrgzju
    Commented Apr 7, 2015 at 15:08

1 Answer 1

Reset to default
1

I finally figured out what happened. The problem was "The guest has two network adapters, one is bridged and has a public IP address which is 128.x.x.219, the other works in NAT mode and has a local IP address which is 192.168.106.129." It seems we should not do that. We should not have two virtual adapters on the same VM, with one of them working in bridged mode (bridged to the public Internet) and the other working in NAT mode (translated to the public Internet).

The solution was to simply remove the bridged adapter in VMWare Player, and save the configuration file. It doesn't really matter if I run the VM using vmplayer or vmrun.

It seems that when the virtual machine receives a connection request through port forwarding, it tries to connect to the request sender, which is on the public Internet, but its attempt goes through the bridged adapter instead of the NAT adapter which results in incorrect checksums. This is probably due to the route table on the VM.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .