1

This has been asked in stack overflow like 7 years back. I don't see the correct answer there. Is there any way to do this?

While this packet keeps on being transmitting, doesn't the other end see the port as being pseudo open? The application is configured to make sure only these ports as used using socket binding. I am unable to get it to work. The application is not connect to the server. On wireshark, (one is a server- which is not behind NAT), the other end is automatically sending the RST ACK (Closing the connection). How do I put in tcp-port-keepalive, so it doesn't close the connection?

Details: I have an application which works perfectly fine in a LAN. P2P.. Now I want it to work behind a NAT, such that a server is never needed. The application has a "server" side which uses port 12345 and the "client" side which uses port 12346. The idea here is to make the server which is actually behind a NAT, appear as if it's open. So as to achieve true peer to peer connection.

2
  • 1
    You'll need to add considerably more details to your question - how the network is set up and what specific problem you're trying to solve - for us to answer that question. In short, if you want to connect private-to-public or vice versa, you need to use NAT or a proxy (which is off-topic here).
    – Zac67
    Oct 27, 2021 at 7:51
  • @Zac67 I have an application which works perfectly fine in a LAN. P2P.. Now I want it to work behind a NAT, such that a server is never needed. The application has a "server" side which uses port 12345 and the "client" side which uses port 12346. The idea here is to make the server which is actually behind a NAT, appear as if it's open. So as to achieve true peer to peer connection. Oct 27, 2021 at 7:55

2 Answers 2

1
  1. To work behind NAT - connect from a public IP address to a server's private IP address - destination NAT aka port forwarding aka reverse NAT is required. You cannot work around that from the private server side.

  2. If both client and server are in the same private network (more precisely: sharing a common addressing domain) then you don't do anything. Simply connect from the client to the server's IP and port.

  3. If client and server are located in different private networks, then #1 applies - the client's private address needs to be translated by source NAT at its WAN gateway. The public destination address needs to be translated by destination NAT at the WAN gateway of the server's network.

  4. Alternatively to #3, a tunnel can be created between the two network, allowing them to share a common addressing domain, so #2 applies.

Trying to work around the necessary destination NAT with some kind of trickery might work with UDP but is is absolutely moot for TCP (that is used by HTTP/S). TCP requires a flawless SYN-SYN/ACK-ACK handshake that you cannot work around.

2
  • But if both the devices are behind a NAT. And the NAT simply translates the port and IP, isn't it possible to send out fake packets with the destination address- thereby making a route open which the NAT will know? Regardless of weather the packet is received by the other end. Once the packet is sent out, doesn't a route appear automatically? Oct 27, 2021 at 9:02
  • 1
    For UDP, maybe. For TCP, you'd need to know the sequence numbers. (which a NAT/firewall may also change.)
    – Ricky
    Oct 27, 2021 at 9:15
2

If you want two hosts behind different NAT's to talk to each other, there must be some internet reachable server to broker the connection. [see also: nat punching] If one side starts blindly transmitting, the other side will never see it, because there's no connection in the other NAT. TCP requires a handshake to setup the connection. Any NAT engine will need to see that full handshake to setup its own connection tracking.

Bottom line, if I'm behind NAT, and you're behind NAT, there's no way for us to directly communicate. We would each need to know something about the other with no channel through which to exchange it.

Your Answer

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

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