TCP connection to guest from host via VMWare bridge networking blocked [M1727]

A. Unable to communicate from a windows 10 host to port 22, 21/20 on a Centos Guest on VMWare
Can you reproduce the problem & if so how reliably?:
Yes, Consistent.
If you can, exact steps to reproduce. If not, exactly what you did & what happened:
1:Install fresh Windows 10 and update OS to latest
2:Install latest CIS 8 and update
3:Install VMWare workstation player v12
4: Start VMWare and create new Guest
5: Install Centos 6
6: Run yum update, switch off SELinux & restart
7: Configure eth0 adapter to obtain IP from router ( in this case)
8: CIS Firewall - Create Global rule to allow any connections to port 22
Allow any outgoing connections from putty (telnet client), Filezilla (ftp client) and vmplayer.exe (VMWare host)
Allow incoming connections to vmplayer.exe on port 22
9: From Guest Centos, ping, ping (router) and ping (Host machine)

  • All these will work
    10: From the Host OS, ping (Centos guest) - this works
    11: Try ssh & sftp from Host OS to guest OS - Doesn’t work
    12: Disable comodo firewall & test in step #11 is successful

One or two sentences explaining what actually happened:
Comodo is somehow blocking connections between Host OS and Guest OS, even though all incoming & outgoing rules are applied.
I also tried to log any blocked incoming Global requests - no result.
Tried logging any successful sent packets - it reports sent packets from putty & filezilla clients
Logging blocked packets for vmplayer doesn’t show any entries.
One or two sentences explaining what you expected to happen:
SSH & SFTP should work as normal.
If a software compatibility problem have you tried the advice to make programs work with CIS?:
CIS 8 on Windows 7 works with VMWare 12 and Centos OS in the exact same configuration.

Any software except CIS/OS involved? If so - name, & exact version:
Yes, VMWare Player 12
Any other information, eg your guess at the cause, how you tried to fix it etc:
Possible incorrect detection of incoming traffic?

Exact CIS version & configuration:
CIS 8.2.04703
Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
Antivirus - Realtime scan enabled
Defense + - HIPS Disabled
Sandbox - Auto Sandbox Disabled
Virusope - Enabled
Firewall - Enabled, Safe Mode
Custom rules as described above

Have you made any other changes to the default config? (egs here.):
Disabled Auto-Sandbox
Firewall config - Allow all incoming on port 22, 23 and any traffic from VMWare application.
Have you updated (without uninstall) from CIS 5, 6 or 7?:
if so, have you tried a a a clean reinstall - if not please do?:
Have you imported a config from a previous version of CIS:
if so, have you tried a standard config - if not please do:
OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Windows 10, 64 Bit
Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
a=None b=None
CIS is the only security app on this machine.

Even though the above issue has been raised for Centos OS on the guest OS, I suspect that this will not matter.
Any OS installed on the guest would not be contactable by the Host Windows 10 OS.
Since there is no firewall on the guest OS running on the VM, the restriction is really from the Host OS denying packets.

This is not a comodo issue, its the way VMWare implements virtual bridge networking using the NDIS6 networking framework on windows with hosts and the same way virtualbox version 5 now does too. Which is one of the reasons why I don’t use VMWare for VM’s and stick with VirtualBox 4.3.x version series as Virtualbox 4.3.x and earlier allows access to VM guests open ports without having to configure the host firewall to allow access.

I don’t believe this is a VMWare issue. The product can use any mechanism to send packets via the OS, it’s the firewall that should control access to the ports and resources.
Earlier version of VMWare does exactly the same thing and I have configured incoming connection globally and also for the vmplayer.exe and that works perfectly. This version of Comodo breaks something and doesn’t even indicate in the logs why it blocked the port.
The firewall needs to have the configuration ability to allow connections to & from the machine.

Unless its a Windows 10 specific bug, I am not able to reproduce on Windows 7. I can access any open port on the guest VM without making any changes to CIS on the host.

Yep, it’s windows 10 & CIS 8 specific.
The exact same combo works on Windows 7.

Please test with version <>.
Thank you.

I have the same issue with Virtualbox as well.

However, it was working fine with Comodo until after the W10 1511 update. Then bridged stopped working. Setting Firewall/HIPS/etc. to disabled didn’t fix the issue.

I tested after upgrading Comodo - Same result.
I also upgraded VMWare to 12.1 on both windows 7 and Windows 10.
It works on 7 as usual, only windows 10 doesn’t work. Disabling the firewall works.
Also another thing I noticed is that the machine is pingable - it’s TCP connections that don’t seem to work - I tried both SSH and FTP.
SSH into the VM from another physical machine works, it’s just the Host not being able to contact the VM hosted on the same machine.

Any update on this ?

While this is an interesting bug there is a workaround that I discovered, in that you only need to create an application rule for “Windows Operating System” that allows out the port you want to connect to on the guest machine. So for example an allow out to destination port 22 and funny enough no allow in rules for global rules does NOT need to be defined and the rule for vmwareplayer.exe is not necessary either. As long as allow out rules are defined under application rules for windows operation system, you can connect to the guest from the host. To create a rule for windows operating system, click browse running application and select Windows Operating System from the application list. Your best option would be to set windows operating system to the allowed application predefined ruleset.

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Hopping in here to say that I’m having the same issue and that the workaround does not work for me. I also tried allowing
Windows 10 host, CentOS guest.

The peculiar thing about is that this bug occurs when I’m on the wireless adapter (Intel 6300 AGN), but does not occur when I’m on the wired adapter (Killer network).
Disabling the firewall or unchecking the “Comodo internet security firewall driver” allows it to work over wireless.

I came across this exact issue, except it did not work at all, when I was beta testing Symantec Endpoint Protection 12.x, a while ago, and they eventually straightened it out.
This is a pretty important issue for those of us running VMs on our machines.
In my case, I could not use NAT due to the need to expose VM ports to the world while testing, but it just happens to work when I’m wired up, so it’s all good.

Please check with Comodo Internet Security V10.0.0.6071 Beta thanks.

I have exactly same problem.
Tried to allow connections for ALL programs but still TCP connections coming from VMs are blocked.
Only way to allow connections is disabling firewall.

It took hours for me to realize that this might be a bug.

Please help with subject.
VMware Host is Windows 10, guest Ubuntu connected over bridged network. Host connected to network over WiFi. I can access guest from host in explorer and copy/paste files over samba, but SSH communication timed out if Comodo firewall is enabled.
It is working with wired connection.

Is it issue with firewall or with WiFi (Intel AC-9560) ?

Check the logs and see how and why it was blocked.

Post the results back here.

Ewen :slight_smile:

Log is empty. I have cleared log, then try ssh and see timeout, then refresh log and nothing. Is there any other logging besides “view logs” ?

A known bug that probably will never be fixed, due note it only affects TCP connections outside the MS file sharing ports and I think some of the netbios ports 135-139. And as you have noticed only occurs when using a WiFi adapter, no issues using a wired NIC.

Btw which version of VMWare workstation are you using? I can’t use any thing newer than the 12.x version series, so I wonder if the bug still applies to the newer major versions.

VMware 15.1.
Thanks for info. But it is kind of strange because I am connecting perfectly with Ubuntu guest samba server (SMBv2) from explorer.
It is interesting to see if someone with non-Intel Wifi have this problem.

PS It seems there is no hope to have it fixed or get workaround, as it exists so long time :frowning: