Author Topic: UPNP NAT for Servers  (Read 1193 times)

0 Members and 1 Guest are viewing this topic.

Offline HaydenRead

UPNP NAT for Servers
« on: August 03, 2016, 06:56:50 AM »
Was thinking it would be good to include UPNP NAT configuration for use with Servers.

If I get time and can work out how and in what section of the code to implement this I may try it myself. Otherwise if anyone else is keen to give it a go it would be great. Or if anyone can give any pointers or suggestions before I start delving into the network code.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4577
  • Total likes: 166
  • Helpful: 106
  • Languages: EN, NO
Re: UPNP NAT for Servers
« Reply #1 on: August 03, 2016, 04:27:52 PM »
Sigh. When is this **** IPv6 finally going to arrive and relieve us from such cludges as NAT? It feels like it has been "next year" for ten years (or more). (Personally, I've finally gotten IPv6, although it is kind of like an early access-thing, but I must still deal with IPv4 until everybody on the other end has IPv6.)

A somewhat related problem is that without NAT, the local firewall becomes much more important. I'm not sure one can poke holes in that with UPNP (or anything but the firewall's administration tools, which require admin privileges), but maybe you can keep any eye out for that issue while reading up on this. I know very little of UPNP.

Offline HaydenRead

Re: UPNP NAT for Servers
« Reply #2 on: August 03, 2016, 08:35:16 PM »
I'm not sure one can poke holes in that with UPNP (or anything but the firewall's administration tools, which require admin privileges), but maybe you can keep any eye out for that issue while reading up on this. I know very little of UPNP.
If the modem / router supports UPNP, then it will generally have calls available for:
  • Getting the External IP Address
  • Opening a port temporarily (how long temporarily is depends on the modem/router, and it generally gives the applicaiton a chance to renew the timeout on the open port)
I know the theory behind implementing it, but not all the specifics.
The basic steps are:
  • Broadcast a request for all UPNP Gateway devices (using UDP)
  • Listen for the replies (hopefully there will only be one Gateway device, but if there are multiple then a procedure for selecting the appropriate one is required).
  • Query the Gateway device using information from the reply to get the action URLs (using HTTP)
  • Post the appropriate port information to the appropriate action URL (using HTTP)

You are also right that IPv6 will get rid of these issues, however I first encountered IPv6 17 years ago, and while it has made inroads to the internet, it still has a long way to go.

There are other options for opening the ports, such as STUN / TURN / ICE, but these rely on a server in the middle.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4577
  • Total likes: 166
  • Helpful: 106
  • Languages: EN, NO
Re: UPNP NAT for Servers
« Reply #3 on: August 03, 2016, 08:43:51 PM »
The piece you quoted wasn't about modems or routers.

Offline DrSuperGood

Re: UPNP NAT for Servers
« Reply #4 on: August 03, 2016, 10:23:22 PM »
Quote
A somewhat related problem is that without NAT, the local firewall becomes much more important.
Only if one is running applications with open sockets and vulnerabilities. The network stack automatically acts as a firewall by discarding all packets that it cannot route to application sockets.

Honestly if you are smart enough to set up a Simutrans server you should be smart enough to read your NAT user manual and configure it appropriate. I have been able to do so since I was 12 (even a kid can do it)... The hard part was actually finding out that it is the "NAT" stopping the server from receiving connections, something that took me many years to find out. However with the rise of Wikipedia and posts like this that is much less of an issue.

People on cheap internet connections cannot host servers anyway as they are behind carrier grade NAT which they have no control over and may block traversal methods. This is especially the case in Europe and Asia, where IPv4 address ranges have long been depleted.
« Last Edit: August 04, 2016, 07:00:02 AM by DrSuperGood »

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4577
  • Total likes: 166
  • Helpful: 106
  • Languages: EN, NO
Re: UPNP NAT for Servers
« Reply #5 on: August 04, 2016, 04:52:07 AM »
Only if one is running applications with open sockets and vulnerabilities. The network adapter automatically acts as a firewall by discarding all packets that it cannot route to application sockets.

Ports are part of layer 4, while network adapters only handled up to layer 2 last I checked. Not that it matter much. The TCP/IP-stack implementations are very secure.

However, I see a lot of open ports on a standard computer, whether Windows or Linux. A firewall on Windows will either block them completely, allowing only local access, or allow only access from the local network. Sometimes, these will ask the user what to do if a program wants to do network stuff. On Linux, I have only done iptables manually, which requires root access.

Offline DrSuperGood

Re: UPNP NAT for Servers
« Reply #6 on: August 04, 2016, 07:07:02 AM »
Quote
Ports are part of layer 4, while network adapters only handled up to layer 2 last I checked. Not that it matter much. The TCP/IP-stack implementations are very secure.
I meant to say network stack. This covers pretty much all kernel level packet management from the hardware right up to just before application level. All these implementations should be very secure today (there was a time they were not, when a computer could be infected by simply receiving a malicious packet!). Largest security risk is at the application level if the programmer does something incredibly stupid such as allowing a buffer overflow to corrupt the stack.

Quote
However, I see a lot of open ports on a standard computer, whether Windows or Linux. A firewall on Windows will either block them completely, allowing only local access, or allow only access from the local network. Sometimes, these will ask the user what to do if a program wants to do network stuff. On Linux, I have only done iptables manually, which requires root access.
Many of the ports might automatically reject incoming unsolicited traffic, or deal with such traffic in a safe way. However again, if the application programmer made a mistake then they could be possible security vulnerabilities.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4577
  • Total likes: 166
  • Helpful: 106
  • Languages: EN, NO
Re: UPNP NAT for Servers
« Reply #7 on: August 04, 2016, 02:42:47 PM »
"might" is not very reassuring.

Offline TurfIt

Re: UPNP NAT for Servers
« Reply #8 on: August 04, 2016, 08:00:45 PM »
Any sane person who cares about the security of their network has UPNP disabled.... With all the buggy cheap routers out there...

But for implementing it, there's not much high level support in Simutrans. You've network_http_post() and network_http_get() as used for the listing announcements, but anything else you'll be implementing yourself. Calling it initially from network_init_server() rather makes sense.

If you need to periodically refresh the UPNP setup, that's likely more troublesome. The announce process is blocking, as in when the listing server doesn't respond, the server locks up. Certainly don't need that happening with UPNP updates too. Hence threading it would be nice (and for the announces too!). And, IMHO, any UPNP support should be disabled by default.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8698
  • Total likes: 300
  • Helpful: 228
  • Languages: De,EN,JP
Re: UPNP NAT for Servers
« Reply #9 on: August 04, 2016, 08:56:32 PM »
The main problem is (as said) that ADSL (where Upnp would be needed) is usually not very good for running a server, due to the asymmetric part. Moreover, the IPv4 might indeed not be a valid full IP, as mentioned (typically for cable TV users in Europe). And the IPv6  support for my sarverlist server was unfourtunately cancelled last year due to too many hacking attempts of IPv6 servers with badly configured firewall and bugs in the IPv6 code in applications. (Thats what they said.)

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4577
  • Total likes: 166
  • Helpful: 106
  • Languages: EN, NO
Re: UPNP NAT for Servers
« Reply #10 on: August 05, 2016, 05:42:03 AM »
In Norway, fiber, which is symmetric, is quite quickly replacing ADSL in urban areas. In my case, I think UPNP is the only sure way to provide access to a server, since I only have access to a relatively limited administration interface (accessed centrally though my ISP, rather than by talking to my router directly). It does allow port configuration, but I don't remember seeing anything about giving machines fixed IPs. Generally, DHCP servers remember which MAC address had which IP address, but I haven't verified that, as I haven't tried setting up any kind of server here that is meant for outside access (nor is my outside address sure to be fixed either).

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8698
  • Total likes: 300
  • Helpful: 228
  • Languages: De,EN,JP
Re: UPNP NAT for Servers
« Reply #11 on: August 05, 2016, 09:51:24 PM »
There are Upnp script which run on the commandline. You can use those along simutrans. The IP issue cannot be solved by Upnp alone: It may not give the correct IP, if this is not a real IP4 address.

For the scripting on linux using minipnp for a prot w┬┤forwarding from port 3333 to 22:
Code: [Select]
upnpc -a 192.168.1.2 3333 22 TCP

In any case, there are only few XML message to send and parse. If someone feel to code this, we can put it in (maybe activate by -upnp switch on the commandline?).