topic Re: Yet Another Port Forwarding Malfunction (The MAP-T chronicles) in Broadband

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

Endgame901 — Wed, 22 Oct 2025 16:50:12 GMT

Hello everyone. Here's the skinny.

I'm trying to run a game server in a Linux VM on a Windows host machine. I'll add the VM connection details below if anyone thinks they're relevant, but the host machine is connected to a standard 5-port dumb switch via ethernet cable, which is connected to my Sky Max Hub via ethernet. So far, so good.

I set up port forwarding on my Sky Max Hub for the VM via the My Sky app. The ports, in particular, are 2456-2458 for TCP/UDP.

My Sky connection details on my router show MAP-T as enabled with a ratio of 1:1. From everything I've read, it's supposed to work. It does not.

I've used several different port checking sites, and there appears to be no open ports at all to my WAN IP, let alone the ports I specifically set as forwarded. It's almost like it's still shared, even though it's 1:1. Weird right?

So I contacted Sky at 11 this morning, asking for MAP-T to be disabled entirely. They said it'd be a couple hours... well that was a lie! So I'm here to see if anyone in the community might have any other ideas. I don't see why it should matter, but I can bypass the 5-port switch and use wi-fi instead, just in case anyone thinks the switch is interfering!

Thanks for any help provided!

Regarding the VM connection details: the ethernet adapter is set to Bridged. Meaning, my host PC and my VM both appear on My Sky as separate connected devices. I attempted to set up port forwarding for the host machine instead just in case. No dice!

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

JimM1 — Wed, 22 Oct 2025 17:47:34 GMT

@Endgame901 Sky Max hub and Map-T are hand and glove!

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

Endgame901 — Wed, 22 Oct 2025 18:29:29 GMT

I'm...not sure what you mean by this? Can you elaborate?

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

JimM1 — Wed, 22 Oct 2025 18:33:05 GMT

@Endgame901 You have a sky Max hub, then you are using the MAP-T network protocol wether it be a 1:1 or a 1:8. Would double check your IP to the server and make it a fixed IP for ever!

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

Endgame901 — Wed, 22 Oct 2025 19:23:34 GMT

Yes I'm aware I'm using the MAP-T protocol. That appears to be the problem. I've already asked Sky to disable it on my router but they're taking their time. So I'm throwing a hail mary here to see if anybody can think of something I haven't tried.

I've checked and rechecked the IP dozens of times. Just to be really clear, this is not a remote virual machine. The virtual machine is running on my own computer. So it's public IP is the same as my computer's public IP, which is the same public IP every other device in my home will have because it's the WAN IP of the router.

The port forwarding rules on the router are set to forward the requisite communications to the virtual machine, and they are not working. This is why I've asked Sky to turn off MAP-T on my router; every other post I've seen here detailing this problem says "If it's not working as designed, Sky needs to turn off MAP-T for you".

I'm just re-iterating everything again because I'm not quite what it is you're suggesting.

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

Chrisee — Thu, 23 Oct 2025 06:26:42 GMT

@Endgame901 not exactly sure what your issue is but the port forwarding on the Sky Max and the use of MAP-T are probably two separate issues. The sharing of external IP addresses that MAP-T allows does upset some VPNs and external access for some applications but has nothing to do with the firewall rules on the hub.

Port forwarding is a means of allowing external devices from accessing an application runjing on a specific internal device behind the hub's firewall. It is a comparatively rare thing these days as systems like uPnP etc has taken over. The port firesrding on the SR213 hub is known to be flaky and while it can be made to work for some gaming applications I would not recommend it for any serious usage. However you can test if it is the issue by temporarily placing the machine running the virtual machine in the Sky Hub's DMZ it isnt something you should do permanently as you have effectively bypassed the firewall. If the issue continues then it is an issue with the address sharing however Sky tell us thst setting up a port forwarding, using the DMZ or enabling uPNP automatically switches off address sharing.

Honestly while the Sky hub is suitable for most domestic networks it is so locked down it is not a good choice for experienced users. Use of a third party router is far better with only one drawback which is loss of the digital voice line which requires a Sky hub. Asus routers work well on most Sky connections as they support the older DHCPv4 Optiin 61 Sky use as a fallback on lines that dont support DHCPv6 PD.

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

Endgame901 — Thu, 23 Oct 2025 18:41:51 GMT

I forgot to mention that I did try to add the VM to the DMZ, but that didn't seem to make any difference either.

Honestly, I'm still entertaining the possibility that I've somehow just done something wrong, because port forwarding isn't that complex. But I see nothing else to configure and I still have no open ports according to any port checker I try.

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

JimM1 — Thu, 23 Oct 2025 18:46:10 GMT

@Endgame901 Are you still showing as being Map-T connected on the sky Max hub?

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

Endgame901 — Thu, 23 Oct 2025 20:25:29 GMT

I am indeed! I planned to call Sky tomorrow to see what the hold up is.

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

-rpnz- — Tue, 28 Oct 2025 12:10:46 GMT

Hi @Endgame901

If your Sky Hub is showing that you're connected with MAP-T and a 1:1 sharing ratio, then we can rule out MAP-T and IPv4 address sharing as the main issue.

Previously we've seen issues where the LAN IP address being used for port forwarding is incorrect, this can be due to the host initially being configured with DHCP but then it's changed. Please check if the LAN host has the same IP as being used for the port forward.

The best advice I can give here is to make sure the LAN host is using DHCP and give it a fixed IP in the Sky Hub UI/App.

May I ask what application you're attempting to port forward? Most game servers and the like often use UDP which won't show up as "open" when you do an external port scan. If using TCP, make sure the application is up and running when you do a port scan, as the port will also not show up as "open" unless the application is listening.

You could also try opening up the same port over IPv6, this will help prove that the LAN host is indeed "listening" on that port and reachable, even if it doesn't help prove that the host is reachable over IPv4.

Please do let me know how you get on, I'm sure we can get to the bottom of it. I can disable MAP-T on your line either way, but I suspect the issue is unrelated.

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

Endgame901 — Tue, 28 Oct 2025 14:28:56 GMT

Hello rpnz!

The application uses TCP and UDP, so I forwarded the port for both.

Just to clarify, by "LAN host" are you referring to the VM or it's host machine? They both show up separately on the router as the VM is using a bridged connection, and I'm not sure how to verify the actual LAN IP for either on the router. Last I checked, the host was .220 and the VM was .219, but I checked them locally via the command line not the router.

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

-rpnz- — Tue, 28 Oct 2025 14:33:31 GMT

@Endgame901 wrote:
Just to clarify, by "LAN host" are you referring to the VM or it's host machine? They both show up separately on the router as the VM is using a bridged connection, and I'm not sure how to verify the actual LAN IP for either on the router. Last I checked, the host was .220 and the VM was .219, but I checked them locally via the command line not the router.

Sorry, I meant the end-host that you're port forwarding to, the one that's listening on the port, so in this case your VM.

Is the VM set to autoconfigure it's interface and IP address from DHCP, or is it manually configured?

Definitly confirm it against the IP the Sky Hub and App thinks the VM has, and then setup a fixed DHCP lease for the VM in the App, to make sure it gets the IP that the port forwarwd is setup for.

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

Endgame901 — Tue, 28 Oct 2025 14:56:00 GMT

How do I verify the port forwarding IP? It only lists the hostname in the port forwarding section of the app. Other sections of the app do list the IP with the hostname, which matches what the VM it says it has (dynamically, I have to add).

I also created a fixed lease in the webconfig, as I couldn't see where to do it in the app.

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

-rpnz- — Tue, 28 Oct 2025 15:11:00 GMT

@Endgame901 wrote:
How do I verify the port forwarding IP? It only lists the hostname in the port forwarding section of the app. Other sections of the app do list the IP with the hostname, which matches what the VM it says it has (dynamically, I have to add).

Ahh OK, apologies I'm not too familiar with the App interface, but sounds like you found it. As long as it things that hostname has the same IP as you have confirmed on the VM, that's good.

@Endgame901 wrote:
I also created a fixed lease in the webconfig, as I couldn't see where to do it in the app.

Great.

I'll flick you a DM so we can check some things

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

Endgame901 — Tue, 28 Oct 2025 15:12:46 GMT

Don't apologize! I appreciate the help.

I'll look out for your DM 🙂

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

Endgame901 — Tue, 28 Oct 2025 15:38:50 GMT

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!

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

-rpnz- — Tue, 28 Oct 2025 15:52:38 GMT

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?

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

Endgame901 — Tue, 28 Oct 2025 16:26:47 GMT

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!

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

Endgame901 — Tue, 28 Oct 2025 16:56:09 GMT

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.

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

Endgame901 — Tue, 28 Oct 2025 17:33:28 GMT

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.