All UDP/TCP traffic no longer connecting

[tealtxgr]

Describe the Bug

I had some raw UDP and TCP resources that were working just fine maybe a few weeks ago, but suddenly none of them are working at all, including the new, a Minecraft server. Previously I had a TeamSpeak and Restreamer instance both working with raw resources but neither are working now.

Incoming requests are routed from a VPS to another machine as a site, btw.

Environment

• OS Type & Version: (e.g., Ubuntu 22.04)
• Pangolin Version: 1.17.0, but was also happening on 1.16.2
• Gerbil Version: 1.3.1, also happened on 1.3.0
• Traefik Version: 3.4.0 (unsure if it was happening before)
• Newt Version: 1.11.0 for newt on both machines
• Olm Version: (if applicable)

To Reproduce

Unsure. I simply create and try and connect to a TCP/UDP anything. The only remotely useful thing in the logs is this from Newt, on the machine that's accessed as a site:

admin-newt  | ERROR: 2026/04/05 21:55:27 Error connecting to target: dial tcp 172.22.0.45:25565: connect: connection refused
admin-newt  | ERROR: 2026/04/05 21:56:38 Error connecting to target: dial tcp 172.22.0.45:25565: connect: connection refused
admin-newt  | ERROR: 2026/04/05 21:56:39 Error connecting to target: dial tcp 172.22.0.45:25565: connect: connection refused
admin-newt  | ERROR: 2026/04/05 21:56:52 Error connecting to target: dial tcp 172.22.0.45:25565: connect: connection refused
admin-newt  | ERROR: 2026/04/05 21:56:58 Error connecting to target: dial tcp 172.22.0.45:25565: connect: connection refused

Expected Behavior

I know this isn't helpful but, "anything at all" haha.

[LaurenceJJones]

In short Newt is complaining that ip:port is getting a connection refused so on that machine with that IP is there a process that listening on 25565 (sudo ss -lntp or sudo netstat -lntp) and is open on the firewall (if any as you may disable the firewall on local machines in a lan environment)

[tealtxgr]

172.22.0.45 is the Minecraft server container. There were other other connections refused- just to other containers that were previously working on TCP/UDP. I'll check those commands for anything prevalent and I wanna make sure Newt is on the right network too....

[LaurenceJJones]

If its inside the container network, just ensure that if the host restarted or docker updated the network may have changed so make sure the ip:port are correct.

[tealtxgr]

Yeah I did, and they were. Nothing looked misconfigured from what I could see. I checked which container was at that IP and it said the correct container and it was fine. I'm mostly lost how ALL the TCP/UDP stuff just isn't working suddenly, really. The config flag is still there, the compose files look correct and unchanged, it's just not routing that traffic or something. Idk.

[xylcro]

Have the same issue with my Git setup. Can't connect to port 22 when a few weeks ago it worked fine.

[tealtxgr]

Yeah I'm not finding anything on my own that may be causing this. If anyone can offer any troubleshooting steps I'd love to try them-- commands I could run in the Newt container to check connectivity, networking configuration suggestions, etc.

[rvescovi]

If it can help you, since 1.17 and latest newt & pangolin-cli updates I need to use the Alias IP address to access remote private resource rather previously I can access by using the final server destination IP

[baldemar-wuda]

After the 1.17.0 update, I can’t connect to tunneled private resources through their internal IPs. I rolled back to 1.16.2, and everything returned to normal.

[oschwartz10612]

@baldemar-wuda @rvescovi there was an issue with 1.17 that was causing the IP to not be available on a private resource when the alias was configured. In the 1.17.1 release this should be fixed. It does not require an update to the clients or newts but you might need to bounce your newts after updating the server. Sorry for the trouble. #2857

@tealtxgr you are having a reachability problem between newt and the targets for public resources. This fix does not fix that.

[tealtxgr]

@baldemar-wuda @rvescovi there was an issue with 1.17 that was causing the IP to not be available on a private resource when the alias was configured. In the 1.17.1 release this should be fixed. It does not require an update to the clients or newts but you might need to bounce your newts after updating the server. Sorry for the trouble. #2857

@tealtxgr you are having a reachability problem between newt and the targets for public resources. This fix does not fix that.

Anything I should look into to find out where the disconnect may be? Newt wasn't having these issues before so I'm not sure why it is now. I can provide any information that may be helpful to narrow it down

[oschwartz10612]

@LaurenceJJones could you continue to help @tealtxgr? LMK if something is up

[LaurenceJJones]

From the newt logs it seems it an access issue with the configured ip:port combination as it being flat out refused, can you provide the output of inspecting the container that you want to target typically via docker inspect <containerid|containername>. you can also use the format option on the inspect just to give me the network settings (saves you accidentally leaking the environment).

docker inspect <containerid|containername>  --format "{{json .NetworkSettings}}"

just so it clear I want the minecraft container network settings

[tealtxgr]

So, I got the network info from the MC container but I decided I was also gonna provide the info for a Teamspeak server that's been running but unused for a little bit, since I know that was working. But when I didn't see the Newt output I expected in the OP I decided to dig a bit more. I went to the raw resources and saw they were using the right container IP but when I put in the container name instead it worked fine. So it's not all UDP/TCP resources, sorry!

I'd like to ask what's the difference between the container IP and the container name in the resource target configuration? It auto-selects the IP if I use the docker container chooser, but it does seem more consistent with the name. Maybe I'm missing something here.

At any rate it seems like everything is fine, but I'll double-check and report back if it's anything particularly important.