Node full cone NAT traversal support for OpenVPN

[zolia]

In order to have a basic NAT support, we should begin somewhere.
Modification of full cone NAT (port restricted full cone NAT) is default on Linux iptables. Since linux installations comprises majority of router setups we probably should start here. IPtables itself can be configured in other NAT types too, but this one looks to be the main one.

Attaching high level concept of how such NAT traversal could work.

There might be many issues with such implementation (such as IP gets blacklisted by FW if it gets traffic from an unknown IP). This can be addressed later, delaying initial CONNECT. For now we solve simple case, that should be most common.

Adapting NAT traversal to our node is a bit more complex, since we do not implement our own transport protocol, but try to use existing plain security protocols (WG, OpenVPN). We cannot and do not want to use any intermitting transport proxies. For best performance we should have plain p2p connections.

Since there is specifics how services are being launched in our node NAT traversal implementation may vary a bit. We cannot have OpenVPN started before datagram tunnel is not set up in a NAT. According diagram above, flow should be like this:

1. Send { Port: 1194, External IP } to node service
2. Client initiates connection ( Dst Port 1194, Src Port: Local Port 1194)
3. Node starts NAT pinger on Local Port 1194 and sends packet to peer { Port 1194, External IP }
   • When NAT pinger receives CONNECT from peer it shutdowns itself.
4. Node service is started on 1194, next CONNECT from peer should reach node service and connection should proceed as normal.

[zolia]

One major obstacle with such solution is that in our case we could support just 1 client per 1 openvpn instance. This does not look reasonable from resources perspective.

As a solution, on Linux platforms we can use SO_REUSEPORT socket option: https://lwn.net/Articles/542629/

This would let us run NAT pinger in parallel, when we need to start communication with a new client. Such random packets would be received by openvpn too, but they should not break existing connection as they would be simply treated as broken / lost / out of sequence packets.

For windows, we have similar socket option called SO_REUSEADDR. It behaves a bit differently than SO_REUSEPORT. Most likely it takes over, and only one socket receives traffic. We need to investigate these cases before proceeding with implementation.

[zolia]

SO_REUSEADDR option is not useful to us as described by #654.
For linux an option could be to use iptables mangle table, but there is no such option for Windows.
We could not use OpenVPN on Windows, but there is no real working go WG option for Windows too.

[AndriusMyst]

IPtables itself can be configured in other NAT types too, but this one looks to be the main one.

1. What are other types of NAT?

2. What is "BROKER" in this context (high level concept for NAT)?

For best performance we should have plain p2p connections.

3. Can you explain more about this solution? What's missing from core perspective?

[zolia]

node POC branch:
https://github.com/mysteriumnetwork/node/tree/feature/MYST-652-NAT-traversal-poc

go-openvpn POC branch:
https://github.com/mysteriumnetwork/go-openvpn/tree/feature/MYST-652-NAT-traversal-poc

Main features:

• punches a hole in Port Address Restricted Full cone NAT from both sides (consumer / provider)
• uses TTL gradual increase to reduce chance of packet being blocked because of reaching other peer too early
• on provider side NATPinger blocks openvpn service startup until session-create is received with consumer IP:PORT parameters
• on disconnect, openvpn service is stopped
• on new session-create, openvpn is started anew after hole is punched

Main shortcomings and issues:

• no checking if consumer / provider is behind NAT, NAT assumed atm.
• no random generation of local port

[zolia]

Since we have:
c.SetParam("lport", "50221")

on client config for openvpen, it binds a port, but at the same time vpn client starts to think it is a server and starts to wait for approprate client certificate. Not sure how to ensure backwards compatibility.