Two clients behind different NATs.
Clinet A --- NAT ----Internet ----- NAT -------Client B.
Can I use UDP for hole punching,After success,I Got the ip and port after NAT.
Can I use the port for TCP connection? Is that possible?
No. TCP ports and UDP ports are completely different namespaces.
Related
I have enabled 1 port [8081] and it's accessible from the remote computer. but the same for other port [7500] not working?
I would like to know the meaning of the below line?
TCP [::]:8081 [::]:0 LISTENING
And how to enable the same for port [7500]?
Attached listening port status:
netstat -na outputs 4 columns of data:
Proto, Local Address, Foreign Address, and State.
When looking for port 8081, you find 2 entries - one for TCP on 0.0.0.0:8081 for IPv4, and one for TCP [::]:8081 for IPv6.
When looking for port 7500, you find 1 entry - one for TCP 0.0.0.0:7500 for IPv4 only.
In both cases, you have local sockets listening via wildcard IPs to all local network adapters, and there is no "Foriegn Address" assigned because a listening socket is not connected to any remote party. TCP sockets in the ESTABLISHED state have remote parties.
You have not shown any code, or explained your network setup, so nobody can really explain why you have 2 entries for port 8081 but only 1 entry for port 7500, or why remote computers can connect to port 8081 but not to port 7500. Maybe those clients are only using IPv6? Maybe your listening computer is behind a router that doesn't forward port 7500? We don't know.
I am debugging some code which is using UDP communications.
My CLIENT is behind a NAT and a Firewall.
My Server is an AWS machine on which I opened said UDP ports.
However, part of this protocol involves the server answering my client. Which I expected not to work (NAT & Firewall). To my surprise, my client is recieving packets from the server!
How is this possible? I mean, TCP (over UDP) has a concept of a connection, so I guess that the NATs and routers can associate an incomming UDP packet as a reply to an egress connection. But how (and why) does this work for a pure UDP protocol? Would my NAT/Firewall let in random UDP into my client machine?
How is this possible?
That's how NAT works. You wrote that the server is answering you client. That means that the client initiated the conversation. It doesn't matter that you're using UDP and not TCP. The NAT device still creates an appropriate mapping to let answers trough. Otherwise all UDP would have been broken behind NAT.
I mean, TCP (over UDP) has a concept of a connection, so I guess that
the NATs and routers can associate an incomming UDP packet as a reply
to an egress connection. But how (and why) does this work for a pure
UDP protocol?
The fact that UDP isn't connection-oriented is irrelevant. Sure, TCP has the concept of sessions, but both have port numbers and that's really all the NAT needs.
Would my NAT/Firewall let in random UDP into my client machine?
It's not "some random UDP". It's a UDP segment from the same IP and port number that the client sent something to.
I have been reading a lot about different NAT traversal techniques, but I am still a little unclear about how it works.
If I open a TCP port on a client machine and send a request to some arbitrary nonexistent server (which won't respond), my client NAT will now have an open channel, correct? Can I then use another (unknown) computer at a different IP address to access that client port if I know both the public and private IP of the client as well as the port number?
Or will my NAT check where my server packet is coming from and block it since it is not from the same IP address as the original request from the client machine?
Thanks in advance!
To answer your question, you need to know a little about NAT's mapping and filtering behavior. First let me state an information about NAT's mapping behavior,
If you send a packet from your internal IP:port through your NAT's IP:port to any address then your NAT creates a MAP between your internal and its IP:port. Other wise no one from outside of your NAT can send you anything.
There are 4 types of NAT,
Full-cone NAT: If you previously sent a packet from your internal IP:port through your NAT's IP:port then any out side host can send packet to your internal IP:port by sending a packet to your NAT's IP:port.
Address restricted cone NAT: An outside host can send packets to your internal IP:port by sending packets to your NAT's IP:port only if from your internal IP:port at least a packet has been previously sent to that outside host's IP address through your NAT's IP:port. Here that outside host's port doesn't matter. Only IP address has to be same.
Port restricted cone NAT: Same as address restricted just this time out side host's port matters. At least a packet previously sent from your internal IP:Port to that outside host's IP:Port through your NAT's IP:Port will allow that out side host to send you packets from its IP:port through your NAT's that IP:port.
Symmetric NAT: Its mapping behavior is a little different than others. For the previous 3 types of NATs, from your internal IP:port no matter where you send your data it will go through the NAT's same IP:Port. But for symmetric NAT for different destination your data will go through NAT's same IP but different Port. And like port restricted cone, incoming packet will be allowed through NAT if a data previously sent to that outside host's IP:port.
So for your scenario only if your NAT is Full cone NAT than some one unknown who knows your NAT's that public IP:port from which you sent a packet to unknown server, can send you data through UDP transport. For other NAT it will be blocked as you did not send any data to that outside host. But for your TCP connection no one can send you any data even if they know your private and public IP:Port as they are behind different NAT. Read details form this answer.
Read details on wiki.
Is it possible to send/receive udp over port 8080? Everything I see says 8080 is strictly a TCP port. I don't quite get why that would be?
Port 8080 is used by TCP or UDP. There is no restriction of Kernel for opening ports 8080 UDP. What happens is that there is a convention to use port 8080 as TCP, like squid proxy, but nothing prevents you from using UDP in it.
If a station simultaneously maintains three TCP connections,can use the same TCP port for the three connections? If yes how it could distinguish packets?
Each connection is made of the below parameters.
(source ip,source port destination ip, destination port, protocol).
Thus, the station can distinguish packets.
Yes, multiple connections to the same IP and port are possible. They're distinguished by the IP and port on the other end of each connection.