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.
Related
Are datagrams a protocol or not?
Is "Ping" (protocol ICMP) used in an IP DATAGRAM? Or is it using other protocols, such as TCP or UDP?
How do you know the message "Reply" the way back?
Why the Tel number stays the same?
https://en.wikipedia.org/wiki/IPv4#Protocol
Datagrams are basically the packets that go back an forth over the network at IP level. Each of these packets can specify a protocol. You can have TCP, UDP, ICMP, etc. (see https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers)
So to answer your question, yes the protocol for datagrams is basically IP.
You can have higher level protocols that run over IP such the one above.
See https://en.wikipedia.org/wiki/Internet_protocol_suite
Ping uses the ICMP protocol.
Are datagrams a protocol or no?
'Datagram' is the name of the unit of transmission in the UDP protocol.
Is "Ping" ( protocol ICMP ) used in a IP DATAGRAM?
The question doesn't make sense. It would make more sense to say that the ICMP protocol is transmitted via IP packets.
Or is it using other protocols, such as TCP or UDP ?
ICMP is a protocol: you said so yourself; and it is layered over the IP protocol.
My friend told me that TCP doesn't need port forward.
What exactly he said is if the server is port forwarded the client can request something and the server will respond without port forward.
And I agreed with that even though I'm not sure it is true.
Later he said it is the same with UDP which I do not believe.
MAINLY THE QUESTION IS
If a client requests something on a server with TCP, does it need to be port forwarded to receive the response?
Also is it the same for UDP?
If the request from the client is a SYN for connect call then only a SYN-ACK response will be allowed through NAT. If the NAT supports simultaneous open connection then a SYN response from server will also be allowed through NAT. After the connection is established then client and server can communicate freely without any restriction. Port forwarding is not needed.
For UDP after a packet from client to server is sent then anything from server can be received through exact same public port of the NAT from which the first packet was sent. No port forwarding needed.
If a client inside firewall connects to a public server through TCP, once the connection is formed, the firewall allows two-way communication. This is what we normally see in our daily usage. My question is: is this also true for UDP?
Since UDP does not have connect, I will modify the question a little bit...
Suppose the client inside firewall sends a UDP packet to a public server, can the server respond back through firewall using the source address and port of incoming packet?
Yes this is called NAT traversal (or UDP punch through) and works in a similar way to TCP - the stateful NAT device is aware you recently sent a UDP packet from a certain end point internally to a certain end point outside and for a period will accept UDP packets from the same outside endpoint and forward them to the same internal end point.
I always prefer the IETF docs than the plethora of conflicting information out there (including on this site):
https://www.rfc-editor.org/rfc/rfc5128
UPDATE: There are other techniques to "UDP hole punching" such as UPnP's Internet Gateway Protocol and PCP. Each has their advantages and disadvantages and I am afraid there is no one solution works on all NATs!
Consider a phone which is connected to wifi with phones A, address as Dynamic Ip ex:192.168.0.34 and its listening over a server socket at port 7567, In what way can i connect to that socket using any programming language if i have another phone B to connect that which is on public ip say 10.0.0.56 and i have the wifi router ip say ex 55.56.89.76 ?
It is not possible to connect directly to a client behind a NAT if you don't use port forwarding. But there is a technique called hole punching to open a port thrue a NAT.
From Wikipedia:
Hole punching is a computer networking technique for establishing communications between two parties in separate organizations who are both behind restrictive firewalls. Used for applications such as online gaming, P2P and VoIP, both clients establish a connection with an unrestricted third-party server that uncovers external and internal address information for them. Since each client initiated the request to the server, the server knows their IP addresses and port numbers assigned for that session, which it shares one to the other. Having valid port numbers causes the firewalls to accept the incoming packets from each side. ICMP hole punching, UDP hole punching and TCP hole punching respectively use Internet Control Message, User Datagram and Transmission Control Protocols. Using TCP nefarious hole punching, it's possible to send compressed SYN packets through into a common ACK path. Numerous software does this.
See also the questions related to this topic.
If i established openvpn connection through udp(proto udp), can i use tcp in it(tcp convert to udp somehow), or only udp?
In short: Yes, you can send TCP through an VPN-Tunnel which is transported via UDP.
In fact you can tunnel any protocol support by OpenVPN no matter what transport you choose.
You can use any protocol you like, even raw IP. OpenVPN simulates a fully-fledged network device (to some extend – whether it's based on the Ethernet or the IP layer depends on configuration) which behaves like any other network adapter. So you can of course use TCP and UDP in it.
The packages sent via the OpenVPN devices are encrypted and passed through the UDP “connection” used by OpenVPN to the remote side, where they're decrypted and passed on to routing to forward them to their final destination (which might be the remote itself).