I need to establish TCP connection with a server located behind the NAT. The simple solution is to reverse the connection and ask the server to connect to the client, but then I am unable to use standard protocols, where client initiates the connection - e.g. FTPS.

Is there as way to cheat the client, so that the client thinks he initiates the connection, while in the reality the connection is established from the server side?

I have a way to notify the server to connect to client with use of alternative comm channel.

2 Answers 2


You can have the server in question perform a 'call home' style connection where it connects back to a home station server that is accessible to remote devices and establishes a remote shell, VPN tunnel or other encrypted and encapsulated connection that can allow remote access for whatever you need.

Reverse Tunnel via SSH is an example of this. You create a scheduled script to create the reverse tunnel 'home' and have it check that the tunnel is maintained and usable or to recreate it if needed.


  • Thanks, this is an idea I'd like to follow. But bacause I have bare metal server It's hard for me to use SSH. Instead I am gonna write my own broker, which does simiar job SSH service does i.e. listening for connection from device behind NAT and routing the traffic to the client connected to this broker. Commented Feb 1 at 14:04
  • Bare metal doesn't prevent you from using an SSH tunnel or similar like HTTPS tunnel etc. Unless you literally mean you have no operating system at all. Bare metal runs applications and services (one you install an operating system) just like virtual machines do. Commented Feb 1 at 15:58

Exposing a server with a private IP address behind NAT is called destination NAT, reverse NAT or port forwarding.

You configure the NAT router to translate (one of) its public IP address(es) as destination to the private address of the desired server, when a specific TCP or UDP destination port is used.

With that direct 1:1 mapping, the actual application layer protocol on top of the transport protocol isn't relevant. Of course, you need to forward all ports that are used by a protocol e.g. TCP/80 for HTTP, TCP/443 for HTTPS, TCP/21 for FTP plus the configured ports for 'passive' FTP, TCP/990 for FTPS, UDP/443 for QUIC, and so on.

As long as the client is behind a common source NAT (actually NAPT) router, there's nothing to configure on that side. Note that 'active' FTP(S) doesn't work with source NAT usually.

  • But I don't control the NAT - it belongs to mobile network provider and I have no public IP to use. Therefore I am looking for some tricky way to place a broker in the middle of Server <-> Client connection to help establish the TCP connection. Maybe there is a technology ready to use in this scenario ? Commented Jan 31 at 12:09
  • Then you need to talk to your provider or use another one. Without a public IP address you can't run a publicly available server. You could establish a VPN connection in the reverse direction (client network to server network) and then tunnel client requests - don't know if that's a valid approach for you.
    – Zac67
    Commented Jan 31 at 12:14
  • 1
    @GrzegorzKa, you seem to be referring to CGN. Remember that carriers that do that have a clause in your ISP agreement that prohibits running services to the public Internet, so they do not care that it blocks your server. Also, remember that home networking and networks not under your direct control are off-topic here.
    – Ron Maupin
    Commented Jan 31 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.