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.
Related
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.
I'm trying to send UPD packets from node A to node B, both are connected to internet through different routers.
I am able to send (and receive) UDP packets between them when they connected on the same network by giving the local destination ip adddress (192.168..) and port number.
Now I'm finding the dynamic ip address of node B using www.whatismyip.com and consider it as w.x.y.z
When I send the packets from A to this destination, I'm unable to receive them at B. I've also setup port forwarding on both the routers.
This is completely new to me. Is there is something else that needs to be done when I want to send packets to a node connected on another network? Please help!!
I can suggest something to check:
Port Forwarding in both the router are configured for the UDP protocol?
If you ping the remote address w.x.y.z, you receive a response? (check if the routers are configured to do so)
Verify also if there are firewall that block the UDP packet that arrives from the Internet (on the routers or on the target machine).
The thing that you can not receive them at B is because NAT will filter all the messages if you haven't build a connection in the netfilter's table. The way to solve the problem is to use a port mapping like UPNP or NAT-PMP. In this way, the destination node's specific port will receive any message from WLAN and send it to this node. But this needs your router support these protocols, if not, maybe you need to use ICE as a realy server to realize it.
What I am asking is if two computers listen to the same port and a packet of information enters the router through the WAN Ip and the same port. Would the packet go to both computers? Neither? One or the other?
IE
computer 1 -(internal IP)-> 192.168.1.3 -(listens to port)-> 4444
computer 2 -(internal IP)-> 192.168.1.2 -(listens to port)-> 4444
computer 3 -(connects and sends)-> 24.157.358.45:4444
packet -> computer 1 AND computer 2
The code in VB6 is:
LAN.LocalPort = 4444
LAN.Protocol = sckTCPProtocol
LAN.Listen
I am using a WinSock object in the Microsoft WinSock Control 6.0 in VB6 Professional
If there is something that needs to be clarified I would be more than happy to.
The router won't send an inbound packet to either machine unless communication has already been established.
If 192.168.1.3 calls out to some other machine (e.g. 4.5.6.7) from its port 4444, the router will assign an arbitrary port on its external address (say 24.157.358.45 [sic] :5555) and pass the packets on to 4.5.6.7. 4.5.6.7 will send reply packets to 24.157.358.45:5555 -- because that's the only address it knows about -- and the router will relay those to 192.168.1.3:4444.
That's the normal course of things, but there are a lot of additional details to this scheme that make it possible to establish communication with a machine behind a router via trickery.
The system of having machines with private IP addresses behind a router with a public address is called network address translation (NAT); it's a pretty deep topic.
From my knowledge of routers, unless port forwarding is setup, the router will discard any packets sent on that port.
If port forwarding is setup, only one of the computers could be setup to receive the packets.
If the packet is an inbound request to establish a new TCP connection with a server that is running behind the router, the router must have an explicit port-forwarding rule configured, either statically in the router's configuration or dynamically via uPNP or SNMP, that tells the router where to route inbound packets on 24.157.358.45:4444 to, either to 192.168.1.2:4444 or to 192.168.1.3:4444, otherwise the packet will be discarded. So no, both of your listening servers will not see the same packet.
Once a TCP connection is established, the router knows which specific LAN machines are associated with which connections and will route incoming packets belonging to those connections accordingly.
The previous answers are correct, you need to enable port forwarding. If it is not enabled port 4444 will be closed on the router.
It sounds like you have multiple servers and want to forward to whatever server is turned on at the moment. This is not possible (*), the router does not care whether or not PC1 or PC2 are listening on port 4444, it will simply forward everything to the address configured in the port forwarding.
(*): Ok it is possible but it takes some extra work.
Solution 1: Trick the router into thinking there is only one server. Give PC1 and PC2 a virtual network interface with the same IP address and forward to that address. Make sure only one of these interfaces is enabled, having duplicate IP addresses in your network can have unintentional behaviour.
Solution 2: Make the router care about which server is on. You will need to write a program to run on the router (or on another server) that can detect which server is on and forward the packets accordingly. If you are using Linux the program iptables can be worth looking at.
If I have two internal computers connecting to the same external IP address through a NAT router, how is the router able to get the traffic to the correct internal computer? It is my understanding that NAT forwards incoming packets to the computer that recently sent outgoing packets to the [incoming packet's] sender's IP address. Since both computers are sending to the same address, does the router forward the packet to both? If that is the case, is it the responsibility of the client software to determine which packets are relevant?
Is it possible if both computers are attempting to connect to the same port?
When you open a socket, you need to address a port of the destination system and open a conjugate listening port on your own system to receive any response. You have to send the destination system your listening port.
Having more than one system using the same modem
When you start a web browser, and go to www.google.com:80, your browser obtains/searches for a free non-system conjugate port from the system for listening. Let us say, the conjugate port is 10000. The listener port is for receiving the http stream back from google.
Then your kid sitting next to you incidentally also browses www.google.com:80 and his/her google session of the play station or xbox-whatever also incidentally is assigned conjugate port 10000.
Both of you are sitting behind a cable modem, and behind the cable modem is your wireless router. And both of your systems are behind the wireless router - All sitting in that sequence, network topology-wise.
To prevent port address collision on the router/modem
Let us say that your cable company DHCP assigns your modem ip4 adress 72.72.72.72. But your wireless router DHCP assigns 192.168.0.10 to your system and to 192.168.0.11 to your kid's system.
When the frame carrying the information of your listener ports passes thro your NAT router, it would translate either one or both listening- ports. Let's say port 15000 for your page and port 16000 for your kid's page.
Your wireless router then sends your requests to google server as coming from 72.72.72.72:15000 and 72.72.72.72:16000.
The google server then responds individually to 72.72.72.72:15000 and 72.72.72.72:16000 and when you wireless router encounters the response, it reaches into the mapping that it has stored and translates 72.72.72.72:15000 to 192.168.0.10:10000 to reach your system but translates 72.72.72.72:16000 to 192.168.0.11:10000 to reach your kid's system.
Running web/game/ftp/etc servers
But what if you have a web server or an ftp server running on your system. What if you have two systems and both have a web server and both web servers are listening on port 80?
Let us say the local ip addresses registered/assigned with your wireless router of your first web server system is 192.168.0.30 and your second web server system is 192.168.0.40.
The wireless router would have a configuration web page usually by default 192.168.0.1:80, unless you changed it. There would be a tab to on the page where you could define/reserve application port mappings.
You could register with your wireless router to reserve the mapping
192.168.0.30:80 => outgoing port 8080
192.168.0.40:80 => outgoing port 8088
So that you have to phone your friends your web/game servers are addressable through
72.72.72.72:8080 and 72.72.72.72:8088 respectively,
where the wireless router would preclude its port 8080 and 8088 from its own dynamic NAT usage.
Of course, 72.72.72.72 is as good as only before your ISP DHCP decide to renew the ip4 address of your modem to say, 72.72.90.200. After which you would have to phone/email your friends and say
Hey, the servers' addresses have changed to 72.72.90.200:8080 and 72.72.90.200:8088 respectively. Or you could subscribe to dynamic dns (ddns) service to use a named domain where the ddns service will need you to install a simple heartbeat utility on your system to help them monitor the address variation. DDNS translation is a separate issue/strategy.
NAT modems
Newer ISP contracts supply you with a modem that has NAT. If so, you have to switch off either the one on your modem or the one on your wireless router. You should not use both - what's the point in translating twice because NAT is simply to prevent address collision. When you switch off NAT from your wireless router, it can operate as a hub switch and not a router anymore so that you could connect it to the modem using one of its LAN socket instead of thro its WAN socket.
The router manages "source" ports that are separate for each computer. While you may be connecting to port 80 on the "destination" the router may assign the source port to some high number port.
Wikipedia sums it up as
Network address translation involves
re-writing the source and/or
destination IP addresses and usually
also the TCP/UDP port numbers of IP
packets as they pass through the NAT.
Checksums (both IP and TCP/UDP) must
also be rewritten to take account of
the changes.
Already good answers are provided, but here is another example:
HOST A addr HOST B addr
10.1.0.2:4040 10.1.0.3:4040
-----------------------------------------
NAT 200.50.50.28:4040 200.50.50.28:4041 (what external host sees)
200.50.50.28 is router's global (internet) IP.
Every port number is unique in the NAT table. And of course the router does all the dirty job of modifying the source and destination addresses transparently.
It uses different ports for incoming external traffic, and the NAT then routes the packets on one port to one internal IP address, and the packets from the other port to the other internal IP address... The iniital request from each internal computer, when it goes through the NAT on the way out, establishes which port will be used for the incoming traffic from the external ip address, and it tells the external server what port to send it's traffic back on for that connection.
RFC3022 provides a lot of information on how this works
Since public facing or external IP Address that was given by Internet Service Provider (ISP) has been discussed, I would like to add on this.
You can ask your ISP to have your public IP Address not change. It will become static, so that you do not have to inform your friends to change the IP Address if they want to access your server inside your Network Address Translator (NAT).
As of this writing, static IP Address cost around 100 bucks. Most of the ISP they call it business account.
You can determine your public facing IP Address by googling "what is my ip address".
From what I understand, each HTTP request uses its own TCP connection (please correct me if i'm wrong). So, let's say that there are two current connections to the same server. For example, client side javascript code triggering a couple of AJAX POST requests using the XMLHttpRequest object, one right after the other, before getting the response to the first one. So we're talking about two connections to the same server, each waiting for a response in order to route it to each separate callback function.
Now here's the thing that I don't understand: The TCP packet includes source and destination ip and port, but won't both of these connections have the same src and dest ip addresses, and port 80? How can the packets be differentiated and routed to appropriately? Does it have anything to do with the packet sequence number which is different for each connection?
When your browser creates a new connection to the HTTP server, it uses a different source port.
For example, say your browser creates two connections to a server and that your IP address is 60.12.34.56. The first connection might originate from source port 60123 and the second from 60127. This is embedded in the TCP header of each packet sent to the server. When the server replies to each connection, it uses the appropriate port (e.g. 60123 or 60127) so that the packet makes it back to the right spot.
One of the best ways to learn about this is to download Wireshark and just observe traffic on your own network. It will show you this and much more.
Additionally, this gives insight into how Network Address Translation (NAT) works on a router. You can have many computers share the same IP address and the router will rewrite the request to use a different port so that two computers can simultaneously connect to places like AOL Instant Messenger.
They're differentiated by the source port.
The main reason for each HTTP request to not generate a separate TCP connection is called keepalives, incidentally.
A socket, in packet network communications, is considered to be the combination of 4 elements: server IP, server port, client IP, client port. The second one is usually fixed in a protocol, e.g. http usually listen in port 80, but the client port is a random number usually in the range 1024-65535. This is because the operating system could use those ports for known server protocols (e.g. 21 for FTP, 22 for SSH, etc.). The same network device can not use the same client port to open two different connections even to different servers and if two different clients use the same port, the server can tell them apart by their IP addresses. If a port is being used in a system either to listen for connection or to establish a connection, it can not be used for anything else. That's how the operating system can dispatch packets to the correct process once received by the network card.