I'm trying to set up some port forwarding to enable a device which lies inside my private home network. It requires a number of ports to be forwarded and a number of guides I have read regarding setting this up says to set port x TCP to forward, port y UDP to forward, and occasionally uses the phrase "Internet Protocol Port" z. What is Internet Protocol ports vs UDP/TCP? Does that mean both UDP and TCP? I've never seen something that forwards IP ports; only TCP/UDP.
I am familiar with TCP and UDP, just not the term "Internet Protocol Port". Where would I port forward an IP port in DD-WRT if not using TCP/UDP?
I see now that I mixed up the terms in my head after reading through the guides. It was Internet Protocol "ID", not "port". That term refers to a pool of protocols of which UDP and TCP are examples. When that guide says to enable Internet Protocol ID it is asking to enable Authentication Header which I gathered is a protocol in itself at the level of UDP or TCP.
Source: http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
Related
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.
In our office we've got an Amazon VPC linked to our office network with a bastion server in the middle.
When I try to ping servers within the VPC it doesn't work. The answer I got from a co-worker was that "ping won't work because ICMP isn't linked in our routing configuration, only TCP."
(I can ping servers on our local business network, and Internet websites).
My question is: Why does ping use ICMP not TCP?
They belong to different layers in the OSI model.
ICMP is layer 3, for networking.
While TCP, UDP is layer 4, for transport.
Ping is echo request/reply, part of the layer 3.
there are ping utilities which use ping-like features over TCP or UDP to test whether a target host answers connection attempts. One of these is Mark Russinovich's psping (https://technet.microsoft.com/en-us/sysinternals/psping.aspx) which can use ICMP or TCP. Technically, it's not the same as ICMP as it's built upon the TCP handshake; in practice, you use it like ICMP ping.
IP protocol datagram header contains a Protocol field to define the protocol used in the data portion of the IP datagram.
How does a TCP packet identify the its application level protocols? I don't see similar fields in the TCP header format. So it all depends on the port number?
If so, does it mean I can silently switch the application protocol on the same port, just like what happens when WebSocket uses a handshake request in the format of HTTP to tell the server to switch from HTTP to WebSocket protocol?
TCP itself does not care about the application layer protocol used. The closest thing is the port number. Port numbers are used to distinguish different connections on the same host. When a packet is received, the operating system uses the port number to determine which program it belongs to. Although many protocols have standard port numbers, you are not required to use them.
So yes, you can switch protocols on the same port.
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.
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.