As UDP is a connectionless protocol, once the forwarder gets a packet and sends it to a target ip, and the target ip responds with data, how can the forwarder know what ip to send the packet to?
If you are talking about a standard gateway, it knows where to send it because the packet has a destination IP address and port.
If you are talking about NAT, then the router must remember what it has recently sent out and accept corresponding incoming packets. The router maintains a session internally, which will stay alive for some configured period.
Related
I'm trying to understand UDP hole punching and I just don't quite get it.
In concept it seems simple but when I put it into practice I can't pull it off.
From what I understand there's a public server we call the hole-punch server. A client makes a request to hole-punch server (this is public). The hole-punch server spits out a public ip and port of the client that just made the request. So long as that port is open then essentially any random client can make a request to that client using that specific port and ip ?
The issue I guess I'm having is, the client is able to make a request to the server. The server is able to send data back to the client on that public port and ip however when another client tries to send a request to that client using that same port and ip it just doesn't go through and that's what's confusing me. If the server can make the request why can't another random client make that request?
The thing to know about UDP hole-punching is that many consumer-grade Internet routers/NAT-firewalls have a policy along the lines of "block any incoming UDP packets, except for UDP packets coming from an IP address that the user's local computer has recently sent a UDP packet to"; the idea being that if the local user is sending packets to a particular IP address, then the packets coming back from that same IP address are probably legitimate/desirable.
So in order to get UDP packets flowing between two firewalled/NAT'd computers, you have to get each of the two computers to first send a UDP packet to the other one; which is a bit of a chicken-and-egg problem since they can't know where to send the UDP packet without being able to communicate; the public server is what solves that problem. Since that server is public, both clients can communicate with the server (via UDP or TCP or HTTP or whatever), and that server can tell each client the IP address and port to send its UDP packets to. Once each client has sent some initial packets to the other, it should also (in most cases) then be able to receive UDP packets from the other client as well, at which point the server is no longer necessary as a go-between.
Once client sends an HTTP request to server, it disconnects from the server and waits for a response. Does server store clients IP and mac address to send the response? Is the clients information stored when the TCP/IP connection is established?
Every tcp/ip packet has source and destination in it. When the listening socket is created and receives the packet it has the source address from the packet. After that it uses that data to send the response.
The MAC address is in the packet as well. If you are on the same vlan it will be the source MAC address. If you are on a different network segment it will be the MAC address of the router. The source MAC address will be used in the response as well. However, the are other things at play with the MAC address like arp tables etc.
You should read about tcp/ip packets, sockets, and basic networking.
I read a post on superuser.com (https://superuser.com/questions/284051/what-is-port-forwarding-and-what-is-it-used-for) that answered everything except for the port that is used. When sending out data from behind a NAT router, what port does the sending device use to send to the router and what port is used by the router once it's sent out, over the internet? I know that when a server receives this packet, it uses the port it was sent by the sending device (client) to know where to send the packet back to. But, this still doesn't answer where the NAT router came up with these two (private and public) ports originally. Do NAT routers just pick random ports and play a game of peek-a-boo with it's sending ports to make it nearly impossible for hackers to use port scanners to find an opening on random nodes on the internet? Please someone put me out of my misery.
The port stays constant across the entire spectrum unless otherwise specified. For example,
Client sends HTTP on 80, router forwards HTTP on 80 private to 80 public. Internet router recieve on public 80 and forwards to private 80.
The only thing that changes at the router (behind NAT) is the requesting IP Address. If I send a packet from my computer on port 80 to am internet site, the router changes the packet Source IP to its IP and then sends it across the globe.
Now, let's say we're on a home network. Here's how things work.
192.168.0.2 send request to router headed to 8.8.8.8 (google) on port 80. Packet gets to router. Router changes the SourceIP from 192.168.0.2 to its Public IP (64.5.5.5). It stores a record of this using various information such as the requesting MAC Address. Packet arrives at 8.8.8.8, which then changes the Destination IP from 8.8.8.8 to 172.0.0.5 (some internal web server at Google) and send the request to the server. When the server send a response, the same process happens in reverse.
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.
So right now I'm using only TCP for my clients - they connect to the server, open socket and freely getting packets.
But what if I will decide to use also UDP in my game? Will they gonna have to open ports? For example, if they are using a regular WiFi, can I send UDP to the client without having opening ports problem?
Thanks.
TCP and UDP are just two examples of transport layer implementations. Both of them are using term 'port' to determine which app should receive incoming packet, but they could be routed/filtered differently by routers/switches/firewalls/etc.
So the answer is no. You will have similar problems with opening ports. Just except 'TCP port xxx should be opened' you have to demand 'UDP port xxx should be opened'.
In most home networks firewall rules allow outgoing packets (requests) to any remote port (on your server for example, where this port should be opened). And when such a packet goes through a router - it creates temporary rule to allow answers come back to the local port from which request packet.
So, normal scenario is like that:
Packet originated from home computer with IP 5.5.5.5. Lets say it has source UDP port 55555, source IP address 5.5.5.5 and destination port 8888.
Packet reaches home router. As it is going from inside - router allows it to pass through and creates rule say for 2 minutes to allow packets targeted to 5.5.5.5 to UDP port 55555.
Packet reaches corporate router before your server. It has rule to pass packets for port 8888 so packet is allowed to go.
Your server receives the packet and processes it. In response it creates packet for IP 5.5.5.5 and UDP port 55555.
Corporate router allows response to go.
Home router allows response to go according to temporary rule.
Your computer receives the response.
Corporate computers and routers often more restrictive to ensure security, so second point could restrict packet if your user (IP 5.5.5.5) is in corporate network.
It is very simplified as in reality there's almost always things like NAT and rules are more complex... But in general it gives the idea how it works internally.