Port forwarding issue with VMware
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have VMware Fusion running on macOS (host) and 1 VM with Windows 10 as guest. Networking is set to Shared (ie NAT).
I would like to connect to a webserver running on the Windows 10 VM, on port 8888.
I gave the VM a fixed IP address, by editing /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf
and adding:
host Windows8x64 {
hardware ethernet 00:0C:29:86:EB:52;
fixed-address 192.168.80.101;
}
Next, I edited /Library/Preferences/VMware Fusion/vmnet8/nat.conf
and added:
[incomingtcp]
9888 = 192.168.80.101:8888
Restarted VMware networking using the commands:
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --start
On the Windows VM, I refreshed the network address using DHCP to make sure it received the fixed address (which is outside the range of DHCP leases).
All firewalls on Windows have been disabled, and the network locations have all been set to private.
When I try telnet 192.168.80.1 9888
to see if I can contact the client machine from the host OS, I would expect either the connection to be established, refused or eventually timed out. To test things out, I have ncat
running on the client (ncat -4 -l -t -v 192.168.80.101 8888
).
This is the output of the telnet command:
telnet 192.168.80.1 9888
Trying 192.168.80.1...
Connected to 192.168.80.1.
Escape character is '^]'.
and after some time...
Connection closed by foreign host.
In other words: the connection was established, but the strange thing is that I'm seeing no activity whatsoever on the Windows client. I've disabled all other networking on the host to make sure that it's connecting to the VMware network.
I found this in the logfile /var/log/vnetlib
whenever the VMware network is (re)started:
VNLNetCfgLookupNATPortFwd - List of NAT forwarded ports is empty
VNLNATReadPortForward - Failed to read TCP port forward config info.
VNL_StartService - Started "NAT" service for vnet: vmnet8
In /Library/Preferences/VMware Fusion/vmnet8/networking
, I found the following (auto-generated) line, indicating that the configuration change for the port forwarding seems to have been read correctly:
add_nat_portfwd 8 tcp 9888 192.168.80.101 8888
At this point, I'm at a loss.
Version info
- macOS Mojave 10.14.3
- VMware Fusion 11.0.2
- Windows 10 Pro version 1809
TLDR
"Something" is accepting a connection to the mapped port, but the traffic is not reaching the guest VM, even though all firewalls have been disabled.
Port forwarding and fixed IP assignment seem to be correct, but the log file is indicating an error.
Update
As per @JensEhrich's recommendation, I added another VM (macOS this time) and tried to connect from MacVM > WinVM. No luck, the connection could not be made. It looks like the firewall on WinVM is silently dropping the incoming packages.
I set up netcat on MacVM and tried to connect to it from both the host as well as the WinVM: both worked, even without port mapping set up for that guest (it seems that due to having a virtual NIC on the host that is part of the NAT, port mapping is only necessary for incoming traffic on the host's network, not on the host itself).
Thus, it seems that VMware NAT is not at fault, but WinVM is still blocking incoming connections, even though the firewall is completely disabled. But even after turning the firewall on, allowing incoming connections and then turning the firewall off again, the issue remained.
virtual-machine nat port-forwarding windows-firewall
migrated from serverfault.com Mar 6 at 15:10
This question came from our site for system and network administrators.
|
show 4 more comments
I have VMware Fusion running on macOS (host) and 1 VM with Windows 10 as guest. Networking is set to Shared (ie NAT).
I would like to connect to a webserver running on the Windows 10 VM, on port 8888.
I gave the VM a fixed IP address, by editing /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf
and adding:
host Windows8x64 {
hardware ethernet 00:0C:29:86:EB:52;
fixed-address 192.168.80.101;
}
Next, I edited /Library/Preferences/VMware Fusion/vmnet8/nat.conf
and added:
[incomingtcp]
9888 = 192.168.80.101:8888
Restarted VMware networking using the commands:
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --start
On the Windows VM, I refreshed the network address using DHCP to make sure it received the fixed address (which is outside the range of DHCP leases).
All firewalls on Windows have been disabled, and the network locations have all been set to private.
When I try telnet 192.168.80.1 9888
to see if I can contact the client machine from the host OS, I would expect either the connection to be established, refused or eventually timed out. To test things out, I have ncat
running on the client (ncat -4 -l -t -v 192.168.80.101 8888
).
This is the output of the telnet command:
telnet 192.168.80.1 9888
Trying 192.168.80.1...
Connected to 192.168.80.1.
Escape character is '^]'.
and after some time...
Connection closed by foreign host.
In other words: the connection was established, but the strange thing is that I'm seeing no activity whatsoever on the Windows client. I've disabled all other networking on the host to make sure that it's connecting to the VMware network.
I found this in the logfile /var/log/vnetlib
whenever the VMware network is (re)started:
VNLNetCfgLookupNATPortFwd - List of NAT forwarded ports is empty
VNLNATReadPortForward - Failed to read TCP port forward config info.
VNL_StartService - Started "NAT" service for vnet: vmnet8
In /Library/Preferences/VMware Fusion/vmnet8/networking
, I found the following (auto-generated) line, indicating that the configuration change for the port forwarding seems to have been read correctly:
add_nat_portfwd 8 tcp 9888 192.168.80.101 8888
At this point, I'm at a loss.
Version info
- macOS Mojave 10.14.3
- VMware Fusion 11.0.2
- Windows 10 Pro version 1809
TLDR
"Something" is accepting a connection to the mapped port, but the traffic is not reaching the guest VM, even though all firewalls have been disabled.
Port forwarding and fixed IP assignment seem to be correct, but the log file is indicating an error.
Update
As per @JensEhrich's recommendation, I added another VM (macOS this time) and tried to connect from MacVM > WinVM. No luck, the connection could not be made. It looks like the firewall on WinVM is silently dropping the incoming packages.
I set up netcat on MacVM and tried to connect to it from both the host as well as the WinVM: both worked, even without port mapping set up for that guest (it seems that due to having a virtual NIC on the host that is part of the NAT, port mapping is only necessary for incoming traffic on the host's network, not on the host itself).
Thus, it seems that VMware NAT is not at fault, but WinVM is still blocking incoming connections, even though the firewall is completely disabled. But even after turning the firewall on, allowing incoming connections and then turning the firewall off again, the issue remained.
virtual-machine nat port-forwarding windows-firewall
migrated from serverfault.com Mar 6 at 15:10
This question came from our site for system and network administrators.
How did you determine ‘no activity whatsoever on the Windows client’? Try typing ‘get [ENTER]’ at after connecting the Telnet session. Also, try running Wireshark on the Windows machine to see what’s actually arriving.
– Jens Ehrich
Mar 6 at 12:36
I determined that there is no activity asncat
will show connections being made, and the process will automatically exit when the connection is terminated. I just ran Wireshark again (on the client), then filtered the output withtcp.port == 8888
and it showed no results.
– ƘɌỈSƬƠƑ
Mar 6 at 12:43
Try connecting to 192.168.80.101:8888 from another VM on vmnet8. This will at least tell you whether the NAT or client is at fault.
– Jens Ehrich
Mar 6 at 12:47
I would expect a "TLDR" (too long; didn't read) to appear before the main body, not after you've read through the entire post.
– Tommiie
Mar 6 at 13:02
@JensEhrich Thanks for the suggestion. I did and updated the post with my findings. Seems that Windows is at fault, though I'm still puzzled what exactly is causing it
– ƘɌỈSƬƠƑ
Mar 6 at 13:32
|
show 4 more comments
I have VMware Fusion running on macOS (host) and 1 VM with Windows 10 as guest. Networking is set to Shared (ie NAT).
I would like to connect to a webserver running on the Windows 10 VM, on port 8888.
I gave the VM a fixed IP address, by editing /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf
and adding:
host Windows8x64 {
hardware ethernet 00:0C:29:86:EB:52;
fixed-address 192.168.80.101;
}
Next, I edited /Library/Preferences/VMware Fusion/vmnet8/nat.conf
and added:
[incomingtcp]
9888 = 192.168.80.101:8888
Restarted VMware networking using the commands:
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --start
On the Windows VM, I refreshed the network address using DHCP to make sure it received the fixed address (which is outside the range of DHCP leases).
All firewalls on Windows have been disabled, and the network locations have all been set to private.
When I try telnet 192.168.80.1 9888
to see if I can contact the client machine from the host OS, I would expect either the connection to be established, refused or eventually timed out. To test things out, I have ncat
running on the client (ncat -4 -l -t -v 192.168.80.101 8888
).
This is the output of the telnet command:
telnet 192.168.80.1 9888
Trying 192.168.80.1...
Connected to 192.168.80.1.
Escape character is '^]'.
and after some time...
Connection closed by foreign host.
In other words: the connection was established, but the strange thing is that I'm seeing no activity whatsoever on the Windows client. I've disabled all other networking on the host to make sure that it's connecting to the VMware network.
I found this in the logfile /var/log/vnetlib
whenever the VMware network is (re)started:
VNLNetCfgLookupNATPortFwd - List of NAT forwarded ports is empty
VNLNATReadPortForward - Failed to read TCP port forward config info.
VNL_StartService - Started "NAT" service for vnet: vmnet8
In /Library/Preferences/VMware Fusion/vmnet8/networking
, I found the following (auto-generated) line, indicating that the configuration change for the port forwarding seems to have been read correctly:
add_nat_portfwd 8 tcp 9888 192.168.80.101 8888
At this point, I'm at a loss.
Version info
- macOS Mojave 10.14.3
- VMware Fusion 11.0.2
- Windows 10 Pro version 1809
TLDR
"Something" is accepting a connection to the mapped port, but the traffic is not reaching the guest VM, even though all firewalls have been disabled.
Port forwarding and fixed IP assignment seem to be correct, but the log file is indicating an error.
Update
As per @JensEhrich's recommendation, I added another VM (macOS this time) and tried to connect from MacVM > WinVM. No luck, the connection could not be made. It looks like the firewall on WinVM is silently dropping the incoming packages.
I set up netcat on MacVM and tried to connect to it from both the host as well as the WinVM: both worked, even without port mapping set up for that guest (it seems that due to having a virtual NIC on the host that is part of the NAT, port mapping is only necessary for incoming traffic on the host's network, not on the host itself).
Thus, it seems that VMware NAT is not at fault, but WinVM is still blocking incoming connections, even though the firewall is completely disabled. But even after turning the firewall on, allowing incoming connections and then turning the firewall off again, the issue remained.
virtual-machine nat port-forwarding windows-firewall
I have VMware Fusion running on macOS (host) and 1 VM with Windows 10 as guest. Networking is set to Shared (ie NAT).
I would like to connect to a webserver running on the Windows 10 VM, on port 8888.
I gave the VM a fixed IP address, by editing /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf
and adding:
host Windows8x64 {
hardware ethernet 00:0C:29:86:EB:52;
fixed-address 192.168.80.101;
}
Next, I edited /Library/Preferences/VMware Fusion/vmnet8/nat.conf
and added:
[incomingtcp]
9888 = 192.168.80.101:8888
Restarted VMware networking using the commands:
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware Fusion.app/Contents/Library/vmnet-cli --start
On the Windows VM, I refreshed the network address using DHCP to make sure it received the fixed address (which is outside the range of DHCP leases).
All firewalls on Windows have been disabled, and the network locations have all been set to private.
When I try telnet 192.168.80.1 9888
to see if I can contact the client machine from the host OS, I would expect either the connection to be established, refused or eventually timed out. To test things out, I have ncat
running on the client (ncat -4 -l -t -v 192.168.80.101 8888
).
This is the output of the telnet command:
telnet 192.168.80.1 9888
Trying 192.168.80.1...
Connected to 192.168.80.1.
Escape character is '^]'.
and after some time...
Connection closed by foreign host.
In other words: the connection was established, but the strange thing is that I'm seeing no activity whatsoever on the Windows client. I've disabled all other networking on the host to make sure that it's connecting to the VMware network.
I found this in the logfile /var/log/vnetlib
whenever the VMware network is (re)started:
VNLNetCfgLookupNATPortFwd - List of NAT forwarded ports is empty
VNLNATReadPortForward - Failed to read TCP port forward config info.
VNL_StartService - Started "NAT" service for vnet: vmnet8
In /Library/Preferences/VMware Fusion/vmnet8/networking
, I found the following (auto-generated) line, indicating that the configuration change for the port forwarding seems to have been read correctly:
add_nat_portfwd 8 tcp 9888 192.168.80.101 8888
At this point, I'm at a loss.
Version info
- macOS Mojave 10.14.3
- VMware Fusion 11.0.2
- Windows 10 Pro version 1809
TLDR
"Something" is accepting a connection to the mapped port, but the traffic is not reaching the guest VM, even though all firewalls have been disabled.
Port forwarding and fixed IP assignment seem to be correct, but the log file is indicating an error.
Update
As per @JensEhrich's recommendation, I added another VM (macOS this time) and tried to connect from MacVM > WinVM. No luck, the connection could not be made. It looks like the firewall on WinVM is silently dropping the incoming packages.
I set up netcat on MacVM and tried to connect to it from both the host as well as the WinVM: both worked, even without port mapping set up for that guest (it seems that due to having a virtual NIC on the host that is part of the NAT, port mapping is only necessary for incoming traffic on the host's network, not on the host itself).
Thus, it seems that VMware NAT is not at fault, but WinVM is still blocking incoming connections, even though the firewall is completely disabled. But even after turning the firewall on, allowing incoming connections and then turning the firewall off again, the issue remained.
virtual-machine nat port-forwarding windows-firewall
virtual-machine nat port-forwarding windows-firewall
asked Mar 6 at 11:30
ƘɌỈSƬƠƑƘɌỈSƬƠƑ
263128
263128
migrated from serverfault.com Mar 6 at 15:10
This question came from our site for system and network administrators.
migrated from serverfault.com Mar 6 at 15:10
This question came from our site for system and network administrators.
How did you determine ‘no activity whatsoever on the Windows client’? Try typing ‘get [ENTER]’ at after connecting the Telnet session. Also, try running Wireshark on the Windows machine to see what’s actually arriving.
– Jens Ehrich
Mar 6 at 12:36
I determined that there is no activity asncat
will show connections being made, and the process will automatically exit when the connection is terminated. I just ran Wireshark again (on the client), then filtered the output withtcp.port == 8888
and it showed no results.
– ƘɌỈSƬƠƑ
Mar 6 at 12:43
Try connecting to 192.168.80.101:8888 from another VM on vmnet8. This will at least tell you whether the NAT or client is at fault.
– Jens Ehrich
Mar 6 at 12:47
I would expect a "TLDR" (too long; didn't read) to appear before the main body, not after you've read through the entire post.
– Tommiie
Mar 6 at 13:02
@JensEhrich Thanks for the suggestion. I did and updated the post with my findings. Seems that Windows is at fault, though I'm still puzzled what exactly is causing it
– ƘɌỈSƬƠƑ
Mar 6 at 13:32
|
show 4 more comments
How did you determine ‘no activity whatsoever on the Windows client’? Try typing ‘get [ENTER]’ at after connecting the Telnet session. Also, try running Wireshark on the Windows machine to see what’s actually arriving.
– Jens Ehrich
Mar 6 at 12:36
I determined that there is no activity asncat
will show connections being made, and the process will automatically exit when the connection is terminated. I just ran Wireshark again (on the client), then filtered the output withtcp.port == 8888
and it showed no results.
– ƘɌỈSƬƠƑ
Mar 6 at 12:43
Try connecting to 192.168.80.101:8888 from another VM on vmnet8. This will at least tell you whether the NAT or client is at fault.
– Jens Ehrich
Mar 6 at 12:47
I would expect a "TLDR" (too long; didn't read) to appear before the main body, not after you've read through the entire post.
– Tommiie
Mar 6 at 13:02
@JensEhrich Thanks for the suggestion. I did and updated the post with my findings. Seems that Windows is at fault, though I'm still puzzled what exactly is causing it
– ƘɌỈSƬƠƑ
Mar 6 at 13:32
How did you determine ‘no activity whatsoever on the Windows client’? Try typing ‘get [ENTER]’ at after connecting the Telnet session. Also, try running Wireshark on the Windows machine to see what’s actually arriving.
– Jens Ehrich
Mar 6 at 12:36
How did you determine ‘no activity whatsoever on the Windows client’? Try typing ‘get [ENTER]’ at after connecting the Telnet session. Also, try running Wireshark on the Windows machine to see what’s actually arriving.
– Jens Ehrich
Mar 6 at 12:36
I determined that there is no activity as
ncat
will show connections being made, and the process will automatically exit when the connection is terminated. I just ran Wireshark again (on the client), then filtered the output with tcp.port == 8888
and it showed no results.– ƘɌỈSƬƠƑ
Mar 6 at 12:43
I determined that there is no activity as
ncat
will show connections being made, and the process will automatically exit when the connection is terminated. I just ran Wireshark again (on the client), then filtered the output with tcp.port == 8888
and it showed no results.– ƘɌỈSƬƠƑ
Mar 6 at 12:43
Try connecting to 192.168.80.101:8888 from another VM on vmnet8. This will at least tell you whether the NAT or client is at fault.
– Jens Ehrich
Mar 6 at 12:47
Try connecting to 192.168.80.101:8888 from another VM on vmnet8. This will at least tell you whether the NAT or client is at fault.
– Jens Ehrich
Mar 6 at 12:47
I would expect a "TLDR" (too long; didn't read) to appear before the main body, not after you've read through the entire post.
– Tommiie
Mar 6 at 13:02
I would expect a "TLDR" (too long; didn't read) to appear before the main body, not after you've read through the entire post.
– Tommiie
Mar 6 at 13:02
@JensEhrich Thanks for the suggestion. I did and updated the post with my findings. Seems that Windows is at fault, though I'm still puzzled what exactly is causing it
– ƘɌỈSƬƠƑ
Mar 6 at 13:32
@JensEhrich Thanks for the suggestion. I did and updated the post with my findings. Seems that Windows is at fault, though I'm still puzzled what exactly is causing it
– ƘɌỈSƬƠƑ
Mar 6 at 13:32
|
show 4 more comments
1 Answer
1
active
oldest
votes
In the end it turned out the issue had nothing to do with VMware. In fact, to connect to guests from the host machine, no port mapping was necessary at all (as the host has a virtual network adapter that is part of the same virtual NAT).
The issue that prevented inbound traffic from reaching the guest VM, was the VPN client running on the guest, which tries to secure VPN endpoints by activating its own firewall and preventing any incoming network traffic.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1411824%2fport-forwarding-issue-with-vmware%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
In the end it turned out the issue had nothing to do with VMware. In fact, to connect to guests from the host machine, no port mapping was necessary at all (as the host has a virtual network adapter that is part of the same virtual NAT).
The issue that prevented inbound traffic from reaching the guest VM, was the VPN client running on the guest, which tries to secure VPN endpoints by activating its own firewall and preventing any incoming network traffic.
add a comment |
In the end it turned out the issue had nothing to do with VMware. In fact, to connect to guests from the host machine, no port mapping was necessary at all (as the host has a virtual network adapter that is part of the same virtual NAT).
The issue that prevented inbound traffic from reaching the guest VM, was the VPN client running on the guest, which tries to secure VPN endpoints by activating its own firewall and preventing any incoming network traffic.
add a comment |
In the end it turned out the issue had nothing to do with VMware. In fact, to connect to guests from the host machine, no port mapping was necessary at all (as the host has a virtual network adapter that is part of the same virtual NAT).
The issue that prevented inbound traffic from reaching the guest VM, was the VPN client running on the guest, which tries to secure VPN endpoints by activating its own firewall and preventing any incoming network traffic.
In the end it turned out the issue had nothing to do with VMware. In fact, to connect to guests from the host machine, no port mapping was necessary at all (as the host has a virtual network adapter that is part of the same virtual NAT).
The issue that prevented inbound traffic from reaching the guest VM, was the VPN client running on the guest, which tries to secure VPN endpoints by activating its own firewall and preventing any incoming network traffic.
answered Mar 27 at 10:21
ƘɌỈSƬƠƑƘɌỈSƬƠƑ
263128
263128
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1411824%2fport-forwarding-issue-with-vmware%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How did you determine ‘no activity whatsoever on the Windows client’? Try typing ‘get [ENTER]’ at after connecting the Telnet session. Also, try running Wireshark on the Windows machine to see what’s actually arriving.
– Jens Ehrich
Mar 6 at 12:36
I determined that there is no activity as
ncat
will show connections being made, and the process will automatically exit when the connection is terminated. I just ran Wireshark again (on the client), then filtered the output withtcp.port == 8888
and it showed no results.– ƘɌỈSƬƠƑ
Mar 6 at 12:43
Try connecting to 192.168.80.101:8888 from another VM on vmnet8. This will at least tell you whether the NAT or client is at fault.
– Jens Ehrich
Mar 6 at 12:47
I would expect a "TLDR" (too long; didn't read) to appear before the main body, not after you've read through the entire post.
– Tommiie
Mar 6 at 13:02
@JensEhrich Thanks for the suggestion. I did and updated the post with my findings. Seems that Windows is at fault, though I'm still puzzled what exactly is causing it
– ƘɌỈSƬƠƑ
Mar 6 at 13:32