VMWare Workstation 12.5.7 Port Forwarding Fails

[fourgotten]

Greetings, O Hive Mind!

I am running VMWare Workstation 12.5.7 on CentOS 7.

Configured port forwarding for RDP to one of my Windows guests on the NAT VMnet. It is not functioning.

I am using Wireshark to capture traffic on both the external IF and the VMnet IF to verify forwarding.

I see traffic on the external IF, but nothing passes to the internal.

I can connect from the localhost to the guest VM, and I see traffic on the VMnet at that point.

I have checked my iptables config, and it is open to all of the traffic that I am using.

Have double-checked my port forward settings and all seems correct:

Here's a wireshark cap (IP addresses obfuscated, but the source is the computer from which I am connecting and the destination is the VMWare Workstation system):

Normally, I would assume that I've done something stupid, but I've been going through everything pretty closely and cannot figure out what I could have done wrong.

I've also noted that there seems to be an editing bug in the NAT settings, wherein if you try to modify any port forwarding configurations other than the last one in the list, the only configuration that you see is the last in the list. I.e., I have an entry for 3389 forwarding and an entry for 80 forwarding. I click 3389 (first in the list) and I see the configuration for 80. But this is tangential to my real problem.

So.... any suggestions?

[wangeryan]

I think you should try to connect the HostIP:3389 from a remote host and monitor the traffic in the guest to verify the port forwarding functions. As regards to the bug your mentioned, you can manually edit the file of /etc/vmware/vmnet8/nat/nat.conf to change the settings. The bug should have been fixed in the latest released WS14.

[fourgotten]

wangeryan​ My apologies. I should have stated that that was my first step in troubleshooting.

Once I realized that I was unable to connect to the guest, I verified that RDP was permitted to that guest, and then kicked on Wireshark on that system to verify that the RDP traffic was not reaching the guest. At that point, I started Wireshark on the host and verified traffic reaching the host, but not passing through the NATted VMNet gateway.

I plan to upgrade to 14 as soon as my license request is fulfilled, so will look forward to that bug being resolved. Maybe the upgrade will incidentally fix my port forwardingissue, as well.

[fourgotten]

UPDATE: Have upgraded to Workstation 14.

Port Forward configuration issue is resolved and I can appropriately adjust different port forwards in the GUI now.

Still get no traffic actually forwarded. Wireshark shows traffic coming in to the interface of the host, but never leaving the internal VMNet8 interface.

Is there, perhaps, some sort of log to check for NAT issues?

[wangeryan]

Would you please upload your wireshark pcap files? Both captured on the host and in the VM.

[fourgotten]

wangeryan​, on the guest, no file is saved, as no packets are captured.

Attached is the anonymized pcap from the host system.

[fourgotten]

BTW, the capture filter was for port 3389.

[wangeryan]

For port forwarding, the destination should be the host system and NAT service forward to the traffic to Guest. According to your pcap file, the source ip is 192.168.124.32 while destination ip is 10.10.10.128, so 10.10.10.128 is the ip address of your host which installed VMware workstation, right? Please also paste the result of "ipconfig /all" on the host system. Meanwhile, you can try to configure the "virtual machine port" to a different port number such as 5201 to check if any different.

[fourgotten]

Please keep in mind that I anonymized the data in that dump for security reasons.

The 192.168.124.32 address is the external system from which I am initiating the RDP session.

The 10.10.10.128 address is the external interface of the host.

The guest is on 192.168.174.110, and the VWNET8 is 192.168.174.0/24.

The port forward is as follows:

I have verified that no other service is using 3389 on the linux (CentOS 7) host, by running netstat -an before and after enabling the port forward. Before, there was no results to netstat -an|grep 3389

Afterward, as expected, 3389 was listening.

That was when I originally configured it under the 12 version. Had some issues getting it to listen on 3389 after the upgrade to 14, but it seems to be doing so now.

Here is the content of the /etc/vmware/vmnet8/nat/nat.conf file:

# VMware NAT configuration file

# Manual editing of this file is not recommended. Using UI is preferred.

[host]

# NAT gateway address

ip = 192.168.174.2

netmask = 255.255.255.0

# VMnet device if not specified on command line

device = /dev/vmnet8

# Allow PORT/EPRT FTP commands (they need incoming TCP stream ...)

activeFTP = 1

# Allows the source to have any OUI.  Turn this on if you change the OUI

# in the MAC address of your virtual machines.

allowAnyOUI = 1

# Controls if (TCP) connections should be reset when the adapter they are

# bound to goes down

resetConnectionOnLinkDown = 1

# Controls if (TCP) connection should be reset when guest packet's destination

# is NAT's IP address

resetConnectionOnDestLocalHost = 1

# Controls if enable nat ipv6

natIp6Enable = 0

# Controls if enable nat ipv6

natIp6Prefix = fd15:4ba5:5a2b:1008::/64

[tcp]

# Value of timeout in TCP TIME_WAIT state, in seconds

timeWaitTimeout = 30

[udp]

# Timeout in seconds. Dynamically-created UDP mappings will purged if

# idle for this duration of time 0 = no timeout, default = 60; real

# value might be up to 100% longer

timeout = 60

[netbios]

# Timeout for NBNS queries.

nbnsTimeout = 2

# Number of retries for each NBNS query.

nbnsRetries = 3

# Timeout for NBDS queries.

nbdsTimeout = 3

[incomingtcp]

# Use these with care - anyone can enter into your VM through these...

# The format and example are as follows:

#<external port number> = <VM's IP address>:<VM's port number>

#8080 = 172.16.3.128:80

3389 = 192.168.174.110:3389

[incomingudp]

# UDP port forwarding example

#6000 = 172.16.3.0:6001

AFAICT, it is configured properly.

In the packet capture, we SHOULD have seen traffic come into the 10.10.10.128 interface, and then leave on the 192.168.174.1 interface to route to the guest. We should also see traffic arrive to the guest.