NAT Punch Through / TNet Online Play

[TomD]

Hi there,

Last year my company completed a project with TNet that allowed LAN play only. This year our client has asked us to expand the game to feature online play as well. We have completed most of the work, but we are facing some serious problems with getting players to connect to each other over the internet.

At the moment we have a Windows server with a static IP running a TNet lobby. Each person that wants to host a game starts a server on their machine and uses the TNet lobby to advertise their game. The lobby works fine, players can see all games being hosted, but the problem is when it comes to connecting.

I would not call myself an expert in network programming, I have a decent level of knowledge but I feel I am getting out of my depth here. My understanding was that TNet's UPnP class would be able to set up port forwarding for the server host machines, but it doesn't seem to have the desired outcome on any router I'm testing with. If I use a tool that uses NATUPNPLib.dll to find the current port mappings, I can see that the correct entry has been made, but yet the target machine can still not accept connections on the specified port, we always get time outs. If I set up port forwarding manually on my router, everything works flawlessly every time. I just need to be able to do this automatically somehow.

Through some reading on the subject, I've came across "NAT punch through", which seems to be different to just using UPnP. I've seen some people have had success with UNet by doing something like hosting a Raknet Facilitator on their server to manage connections. Is it possible to do something like this with TNet? Is there anyone that has had this problem and has managed to solve it?

[cmifwdll]

I'm interested in this as well.

Have you tried opening the port in Windows firewall (and any other application-based firewall), but NOT opening it on the router (letting upnp do that for you)?

If that works, then I think there's a way to programmatically add a rule to Windows firewall which should solve the issue.

[TomD]

I'm interested in this as well.

Have you tried opening the port in Windows firewall (and any other application-based firewall), but NOT opening it on the router (letting upnp do that for you)?

If that works, then I think there's a way to programmatically add a rule to Windows firewall which should solve the issue.

Yes this was one of my first thoughts too, unfortunately it's not the firewall that's the issue though. I've tried making sure the ports are unblocked and even disabling the firewall altogether. I don't think the issue is that the port is blocked, I don't think the port is being forwarded to my machine at all.

[ArenMook]

TNet doesn't do NAT punch-through. It's a hack for UDP connections, while TNet primarily uses TCP. Also as I understand it using IPv6 removes the need for NAT punch-through altogether.

TNet will use UPnP to open the port for you, if possible -- but not all routers support it, nor support it the same way. Apple routers have their own special method for example, because... Apple. You can launch TNServer.exe on its own to see the result of it opening ports. You mentioned that you see ports being opened -- that means the TNet part of it is working as expected. If inbound connections still can't be established, then you have something else blocking the path. For example having 2 routers on the network instead of just 1, or having some local firewall or program such as peerblock hindering your efforts.

[cmifwdll]

TCP punch through is a thing as well. It's slightly more complicated than UDP punch through, but entirely possible. IPv6 should remove the need for NAT, but IPv6 isn't fully rolled out yet, so some players are stuck with IPv4.

I think the idea TomD and I share is TCP hole punching would act as a failsafe for UPnP. Often UPnP fails (I've never had the UPnP part of TNet report a success) for users, and, being users, they are often too inexperienced / inconvenienced to open the port on their router manually. Hole punching would, in theory, eliminate that problem. I don't have a server or a second LAN to test on, so unfortunately I can't test this theory. I believe it would require 3 sockets all bound to the same port. Socket #1 connects to the facilitator, Socket #2 accepts connections (as the TcpProtocol class currently does), and Socket #3 would be used for sending the SYN packet. You can find a PoC in C# on github doing something similar, so it's definitely possible. However, that PoC is primarily for connecting two peers. In TNet's case, we need to connect multiple clients to a single server, so might need to adapt it.

It's an interesting problem to solve, and making port-forwarding a thing of the past would be beneficial to everyone.

[Yoi]

I know this is an old thread, but did you guys make any progress on this matter?

[ArenMook]

No I haven't. Focusing on making the game atm. I'll likely revisit this when the game is closer to release.