Yet Another Port Forwarding Malfunction (The MAP-T chronicles)

[Endgame901]

Sorry for the brevity: this thing killed the DM I sent to you, and then said I reached the limit of messages I can send!

• It's not NATed
• not sure how to check if the VM has a default route out of the router
• VM internet access is fine tho.
• It isn't firewalled by the host. Virtualbox hooks in at the driver level before the Windows Firewall has had a sniff. I specifically created a rule to allow traffic to the executable just in case though.
• I can ping from the VM's host and a completely different device
• I don't think the messager likes me entering IPv4/6 addresses or MACs. It thinks it's HTML, I think. When it let's me try again later I'll try again!

[-rpnz-]

Thanks for those answers.

Can you tcpdump or Wireshark on the host whilst trying to connect to the port from somewhere on the Internet, and see if packets are reaching the host?

[Endgame901]

So what I've tried is running tcpdump on the VM while trying to netcat to it from my Mac connected through my phone's hotspot. The connections are being refused immediately, but tcpdump is showing no dropped packets.

Hopefully this is what you wanted me to test, cause Wireshark is still installing on the windows host for some reason!

[Endgame901]

I was able to get Wireshark installed, and it looks like packets are being refused. RST and ACK flags are set on the response packet from my windows host to the remote server for TCP. For UDP I get "destination unreachable" ICMP responses to the remote server.

[Endgame901]

Sorry for the slew of responses (I don't think I can edit them!), I should point out that the destination IP is actually the LAN IP for the VM. So I suppose the port forwarding is working, but there's a firewall rule in place that's still preventing communication... except I turned off every firewall I could and the problem was still happening. I even made sure the iptables in the VM accepted all incoming connections. Wireshark still shows TCP connections being rejected and UDP connections with unreachable destinations.

[-rpnz-]

Perfect, so a TCP RST from the VM itself means that the application is not listening on that TCP port.

But yes, the good news is that the packets are being forwarded through to the VM, and it's the VM saying "no".

[Endgame901]

What would explain the host PCs failures then? I'm not getting RST and ACK flags, but wireshark shows several retransmittion attempts but no successes.

[-rpnz-]

the host should just be forwarding frames at layer 2, as the interfaces are bridged.   It may be able to do layer 2 firewalling, but it sounds like that's not an issue as you're getting packets to the VM.

What are you seeing from the host?

[Endgame901]

Sorry I wasn't clear: As a test, I changed the port forwarding rules to point to the host PC, not the VM. That's when i got the retransmission errors.

Possibly cause nothing was listening on those ports?

[-rpnz-]

---

@Endgame901 wrote:

Sorry I wasn't clear: As a test, I changed the port forwarding rules to point to the host PC, not the VM. That's when i got the retransmission errors.

Possibly cause nothing was listening on those ports?

---

Ahh.   Yes, depending on the server's firewalling/filtering policy, it will either send back a TCP RST to proactively tell the client that the port is closed, and then the client should give up immediately, or alternatively (as you have seen on your host), it can silently discard the TCP SYN packet without sending a RST, in which case the client will retry until it times out.