So given a network environment as below:
+-----------+ +-------+
| ISP Modem |<----> ... internet ...<------->|Remote |
+-----------+ |Server |
| +-------+
|
|
+------+ +-----------+
|Laptop|-------|Wifi Router|
+------+ +-----------+
Say there is a TCP connection from my laptop to the remote server. When a new public IP address is assigned to the ISP modem due to DHCP renewal, is it going to break the TCP connection? Do I have to recreate the socket?
My understanding is that this should not break the existing connectivity, as the ISP modem is merely a hop on the route at the L3/IP layer. A new public IP address should at most cause some packet loss, which should be retried by TCP protocol.
However this does not match what I observed in reality. I noticed the existing TCP connection won't work any more and requires a re-connection.
I am lacking enough understanding around how the network works at this layer. Could someone please help me understand what is happening under the hood?
NOTE: (I think) This is a different case as in What happens to TCP socket when IP address changes?, in which case the source/target IP of the TCP connection is changed. In my question above, it is the modem IP address changes.
Related
If I type ipconfig in my system, I am getting an ip address which is different from what I get from google(what is my ip). Which IP address needs to be considered?
The ipconfig command on Windows provides the actual address used by the computer.
Address given by 'what-is-my-ip' tool is the publicly advertised address of either the Proxy server or the Gateway Router via which the computer connects to the Internet.
{ Internet } --> what-is-my-ip sees
+ all computers behind gateway
| as 54.102.3.209
|
|
| 54.102.3.209 --> Public address of Gateway
+------+------+ Advertised to the internet
| Gateway |
| Router | --> NAT is performed by Gateway
+------+------+
| 10.1.1.254 --> Internal address known to LAN
|
|
+-----------+----------+
| | |
+---+---+ +---+---+ +---+---+
| host 1| | ..... | | host n|
+-------+ +-------+ +-------+
10.1.1.15 10.1.1.101 10.1.1.4 --> Actual addresses of computers in LAN
(shown by ipconfig)
IP Address uniquely identifies the computer in a network.
There are 2 kinds of addresses:
Public (Globally unique and need to be purchased),
Private (Locally unique and free)
(10.x.x.x, 172.16.0.0 to 172.31.255.255, 192.168.x.x)
It is usual practice for LANs (local area networks) to have private addresses for all computers, and only one public address for the Gateway Router.
This method of using private addresses for all computers and only one public address for Gateway provides these 2 major benefits:
Cost of owning IP Addresses can be reduced (all private addresses are free)
Depletion of IP addresses can be controlled
(Every device on Internet cannot get a unique public address, as the number of addresses supported by IPv4 format is far lower than the number of devices connected to the Internet)
Gateway Router is the device that connects the LAN or groups of LANs to the Internet.
The Gateway needs to have a public address, in order to allow the internet hosts to reach it.
The Gateway router uses the technique of Network Address Translation (NAT) to allow the computers behind it, which have private addresses, to reach the internet, via the gateway.
The internet sees the address of Gateway Router as the IP address of all computers with private addresses that are behind it.
ipconfig returns your local ip address. May be you are in some local network and connected to ani switch or router or mikrotik.
Ip address is returned from "what is my ip" is the ip addres of this router/switch/mikrotik.
If you type ipconfig you get your local address, which is typically not the public address seen on the Internet.
Just to explain you that, take a look at this picture:
https://www.devadmin.it/wp-content/uploads/2018/07/072418_1033_Accessoremo1.png
What does it mean?
You have an address to talk to your router.
Your router has another address to talk to your Internet Service Provider.
Typically, there are different scenarios, based on how the Internet Service Provider manages the IPs on the public Internet.
You can have a dynamic IP assigned only to your router. Please, take a look at the following image: https://www.devadmin.it/wp-content/uploads/2018/07/072418_1033_Accessoremo3.png
You can have a dynamic IP shared with other routers. Please, take a look at this image: https://www.devadmin.it/wp-content/uploads/2018/07/072418_1033_Accessoremo4.png
You can have a static IP. It means that your Home network is always reachable from outside with that IP. This typically needs a special contract with you ISP and you may pay more money to have this contract. Please, take a look at this image:
https://www.devadmin.it/wp-content/uploads/2018/07/072418_1033_Accessoremo2.png
When I say Dynamic IP, it means that your ISP can dynamically assign an IP on the Internet every time you connect to the Internet.
You should think about your internal IP as the room in your house where you are located (bedroom or kitchen) and your ISP's IP assigned to you is the building where you live (a street address).
If you live in a condominium, different people can have your same address.
In that case, think about the IP between your ISP and your router as the apartment number.
Your ISP knows the number of your apartment and knows how to deliver messages to you, no matter if you are in the bedroom or in the kitchen.
It is your private router that knows in which room of the apartment you are. Think about rooms as the devices you have in your flat (Computer, Tablet, Smartphone, etc.).
Your device only returns by ipconfig its actual IP address, not the public IP.
Sites like "What is my IP" cannot read your device internal IP and they see your public IP on the Internet.
Sorry for the examples, but I think this is a good way to understand the topic.
Does TCP in applications will be reliable if I will use it over UDP VPN?
For example, I have VPN server with some application listen TCP on 10.8.0.1:8080
and I will connect from TCP from host 10.8.0.2 to 10.8.0.1:8080. Will it be reliable?
|----------| udp tunnel |----------|
| Server |----------------------| Client |
| 10.8.0.1==========tcp=============10.8.0.2 |
| |----------------------| |
|----------| |----------|
TCP is a protocol on top of IP. IP by itself is unreliable, so all the reliability is done at the TCP protocol level. If you use a UDP based VPN it usually encapsulates the IP into UDP, i.e. an unreliable protocol (IP) into another unreliable protocol (UDP). But since the reliability is implemented at the TCP level this does not matter, i.e. TCP over IP over UDP VPN is still a reliable protocol.
How is ICMP NAT traversal supposed to work if the NAT device in question rewrites outbound ICMP packets?
Diagram
=========================================================================================
| CLIENT | <---> | NAT-C | <---> { internet } <---> | NAT-S | <---> | SERVER |
=========================================================================================
19.19.19.19 (external addresses) 72.72.72.72
192.168.0.2 192.168.0.1 (internal addresses) 172.16.0.1 172.16.0.2
Mechanics
A quick overview of ICMP holepunching as described in pwnat:
SERVER sends ICMP Echo Request packets (pings) to some other host (e.g. 3.3.3.3) to open up a hole in NAT-S. When CLIENT wants to connect, it sends an ICMP Time Exceeded packet to NAT-S, which is supposed to get routed to SERVER. For said routing to work, CLIENT constructs the ICMP Time Exceeded packet by embedding within it the same packet (ICMP Echo to 3.3.3.3) it expects SERVER to be sending in the first place.
Problem
If CLIENT needs to embed the same (ICMP Echo Request) packet as it left NAT-S in its ICMP Time Exceeded reply, it must know the packet's query ID. But how does it know this query ID?
According to RFC 3022 Section 2.2, when NAT-S encounters the outbound ICMP Echo Request, it rewrites the packet's query ID field to a unique external query ID so that it can route future ICMP Echo Replies with the same query ID to SERVER.
Given the problem above, it would seem that the premise behind pwnat and ICMP holepunching is invalid and it's never supposed to work. Am I missing something here?
Thanks in advance :)
You're correct about the query ID.
pwnat rarely works nowdays. I happened to know this icmp punching thing years ago, and interested in this idea. I had read the source code of pwnat and re-implemented it in Go by myself. Only basic NAT devices (rfc 1631 describes) which does simple address translation may work with it, any NAPT device which has robust NAPT implementation won't do.
Besides the identifier problem, (by the way, the source code of pwnat use 0 as the identifier of original request) pwnat didn't give the right checksum of original ip header which may lead to the NAT-S dropping the TTL exceeded message(if the packet can reach there).
More serious, according to rfc 5508,
when the NAT device receives the ICMP Error packet from the Private Realm, the NAT device uses the packet embedded within the ICMP Error message (i.e., the IP packet from the client to the server) to look up the NAT Session to which the embedded packet belongs. If the NAT device does not have an active mapping for the embedded packet, the NAT SHOULD silently drop the ICMP Error packet.
It means the ICMP Time Exceeded packet from the client wouldn't pass through the NAT-C. This paper does mention this scenario and recommends other solutions.
When i try to use [nc -l] command with my private IP address,i am able to create a client server model.But it doesn't work when i try to use my public IP address with the same port number.It gives me the following error:-
nc: Can't assign requested address
Why??
Your problem is that your public IP is the IP of your router, not your computer.
Simplified, your network probably looks like this (IP addresses are only examples):
+--------------+ +-----------------+----------------+
| PC |-----|Router (internal)|Router(external)|---... Internet
| 192.168.0.10 | |192.168.0.1 |123.132.122.133 |
+--------------+ +-----------------+----------------+
Your PC's internal address is 192.168.0.10, and that's the only address it knows. The router routes traffic to other networks; for that it has two interfaces, the internal one with the address 192.168.0.1 and the internet-facing one (123.132.122.133). On your PC, you can't listen on the latter address, since that's the router's address, not the one of the PC.
So the solution is to listen on the internal IP, and setup the router to forward traffic of the respective port to the corresponding port on your PC. Beware of the security implications, though! (E.g. leaving a root shell open to the internet might not be the best idea.)
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.