Say you have a router with external ip 42.1.98.9, with the port 10443 set to forward all incoming TCP/UDP packets to host 192.168.1.200. The routers internal network address is 192.168.1.100.
say there are two NICs connected to the router, with internal IP 192.168.1.200 and 192.168.1.300.
I've noticed that packets sent to socket 42.1.98.9:10443 gets redirected to 192.168.1.200, which is the expected behaviour.
However, say the computer 192.168.1.300 sends a packet to socket 192.168.100:10443. In other words a computer from inside the network is sending a packet to the router, in a port that should theoretically redirect incoming packets.
On that scenario, I'm not noticing the packets being redirected to the proper host -- 192.168.1.200.
Why is that? Does port forward on the router occur only for packets being sent to its external IP address?
Thanks
Yes, generally port forwarding is only from the external address to internal addresses. I'm guessing a commercial-grade router could be programmed to do what you want, but not any home router I've ever seen.
You should be able to use the router's external address from inside the network though (i.e., send packets from 192.168.1.300 to 42.1.98.9:10443 and it should redirect to 192.168.1.200:10443).
Related
Suppose that two computers use the same Wi-Fi to access the Internet. Each of these computers has the same program installed, which is bound to the same UDP port. I want to know, since both computers have the same external IP address and listen to the same port but on different machines, what will be the result if a UDP datagram is sent to this common external address and to a common port, then which machine will receive it and how to send it each machine its own personal datagram?
The router will not forward the packet to either computer, since it doesn't know which one it should forward to.
In fact, even if the program was only running on one computer, the router still wouldn't forward the packet. It has to see outbound traffic going from the computer to the outside world first, before it decides which external port to use for forwarding inbound traffic back to the computer. And the router might not decide to use the same port on the public IP that the computer used on the private IP.
This is why everyone hates NAT and likes IPv6.
When a server want to create a socket, it will use a combination of its IP address and some well-known port, let us say 80. So, when a packet arrived, both the server IP and port 80 will be used to decide whether the packet goes to that socket or not.
The question is why do we need to check the IP address of the server, since the packet (aka datagram) passed the network layer check and was certainly destined for this server. In other words, the network layer will not pass the packet to transport layer if the destination IP is not the server IP, so why do we use the IP address in the socket?
And if a host (a client or a server) created multiple sockets (network processes) using both its IP and some port numbers, is there any case where the IP could be different in these sockets?
Thanks in advance!
Why do we need to check the IP address of the server, since the packet (aka datagram) passed the network layer?
The Data Link Layer uses Media Access Control (MAC) addresses to direct packets. When a packet arrives at your computer operating system (OS), it arrived either because the MAC address matched the hardware address or it was a broadcast (ff:ff:ff:ff:ff:ff).
Once the packet is received, your OS determines if it is destined for an IP address assigned to the computer. At this point, the OS has several options:
If the IP address matches an assigned IP, deliver to any waiting applications or reject the packet and handle any needed Internet Control Message Protocol (ICMP) required.
Should the IP not match an assigned, your OS checks if IP routing is enabled. Then either rejects the packet issuing any required reply or forwards the packet to the destination IP in the routing table by creating a new packet targeting the MAC address of the destination router.
If a host (a client or a server) created multiple sockets (network processes) using both its IP and some port numbers, is there any case where the IP could be different in these sockets?
If your OS assigns more than one IP address to an interface, all of those IP addresses would be available to be used. You can open sockets using any available IP (usually INADDR_ANY or similar). In a listening context, your port will be available to every IP address assigned. In a transmitting context, your IP will be set depending on the outbound interface.
I have a UDP client that calls connect(), send() and recv().
The server has multiple IP addresses. If the reply from the server is not from the same IP as the query, then recv() times out. I have read elsewhere that this might be because the client is calling connect(), so it will only accept a reply from the same IP.
Is there a way to ensure the server always replies from the same IP as the query? I would like the server to listen on all interfaces.
Update: If the client does not call connect() and calls sendto() instead of send(), then recv() correctly receives the reply from the server. I would still rather fix it on the server side by sending the reply from the same IP that the query came from. There is no routing happening on the server, it's one network interface with several IPs.
This makes sense if the client calls connect to one IP address and port, it won't receive a UDP datagram sent from a different IP or port.
If you want your server to listen on all ip's and all ports you'll need to program at the ethernet layer (raw sockets). Check out this link.
When programming in raw sockets you can check in your code for the IP address that the datagrams were addressed to and respond from the appropriate IP.
According to "Computer networking: a top-down approach", Kurose et al., a UDP socket is fully identified by destination IP and destination port.
Why do we need destination IP here? I thought UDP only need the destination port for the demultiplexing.
The machine may have multiple IPs, and different sockets may be bound to the same port on different IPs. It needs to use the destination IP to know which of these sockets the incoming datagram should be sent to.
In fact, it's quite common to use a different socket for each IP. When sending the reply, we want to ensure that the source IP matches the request's destination IP, so that the client can tell that the response came from the same server it sent to. By using different sockets for each IP, and sending the reply out the same socket that the request came in on, this consistency is maintained. Some socket implementations have an extension to allow setting the source IP at the time the reply is being sent, so they can use a single socket for all IPs, but this is not part of the standard sockets API.
I think that you are confusing UDP with Mulitcast.
Multicast is a broadcast protocol that doesn't need a destination IP address. It only needs a port number because it is delivered to all IP's on the given port.
UDP, by contrast, is only delivered to one IP. This is why it needs that destination IP address.
Say I have a router with IP 42.98.1.70, with 2 NiCs connected to it with IPs 192.168.1.200 and 192.168.1.300. The router has port forwarding on port 10433 to redirect packets to 192.168.1.200. The routers internal network IP is 192.168.1.100.
When NIC 192.168.1.300 sends a packet to socket 42.98.1.70:10433. the host 192.168.1.200 gets a packet from socket 192.168.1.100:48900, which as far as I know, looks like a hole punched socket setup by the router.
So theoretically, if host 192.168.1.200 replies with a packet to socket 192.168.1.100:48900, that packet should eventually get back to host 192.168.1.300, since the router should bridge the two via its internal table mapping, aka 'UDP hole punching'.
However, the packet sent back to 192.168.1.100:48900 from 192.168.1.200 never reaches 192.168.1.300.
i'm suspecting that what could be going on is that UDP hole punching doesn't work in between NICs on the same network. It only works between a source that is external to the network and one that is within it. Is that the case?
After reading this RFC - https://www.rfc-editor.org/rfc/rfc5128, it looks like what i was trying to do is called "hair pinning". Although some routers support it, not all do. Apparently mine is one of those.