Question How do LANs connected to the same WAN appear as unique networks?

[New_Tech]

I was having a conversation with someone more educated in networking about how two LANs connected to the same WAN can be seen as different networks. I have a feeling this an elementary level question but there is definitely something I am missing. Say two networks with the same default gateway IP exist and are connected to the same WAN. The logic I have says both networks will receive the same information called for by either network. This is obviously wrong but I'm not sure why. Can anyone explain why this is wrong? He mentioned something about every network receiving a unique WAN address but I don't understand what that means.

Thanks in advance and sorry if this is the wrong place to ask this kind of question. Please direct me to the correct place for this question if it is wrong.

 

[mv2devnull]

At least two solutions come to mind:
1. IPv4: The (private) LANs do not exist, officially
2. IPv6: Every IP is unique

 

[New_Tech]

At least two solutions come to mind:
1. IPv4: The (private) LANs do not exist, officially
2. IPv6: Every IP is unique

First, what do you mean by "officially"?

Second, I may not have expressed the full extent of the question. What I mean is there are two LANs with default gateways with the same IP. Along with that, there are two devices connected to each LAN and both sets of devices share the same IP addressing scheme:

Default Gateway IP: 192.168.0.1
Devices connected to the LANs: 192.168.0.2 and 192.168.0.3

How is it that if the device with 192.168.0.2 requests a website lets say on one of the two LANs, the second LAN and device with matching IPs to the one making the request does not ALSO receive the information? What delineates the two?

My understanding is that many routers come preconfigured with the same IP scheme and the one used in this example is a common one. If this is wrong, feel free to correct me.

 

[mxnerd]

If this is what you mean

Site A :
192.168.0.1 - default gateway
192.168.0.2
192.168.0.3
has public WAN IP a.b.c.d

Site B :
192.168.0.1 - default gateway
192.168.0.2
192.168.0.3 <--- running website
has public WAN IP w.x.y.z

machine 192.168.0.2 wants to visit website on site B 192.168.0.3?

in that sense, site A & site B are not on the same WAN.

Think of WAN IPs as phone numbers, private devices as handsets.

to visit machine 192.168.0.3 running the website, you have to give client machine in site A the WAN IP w.x.y.x, or a DDNS name and you have to do port (80, 443 or any ports you defined) forwarding on site B's router to machine 192.168.0.3

 

[mv2devnull]

A device is connected to a network. A subnet. It has an IP address that is within the address range of that subnet.

When it wants to communicate with a device, whose IP is not within that subnet, it will send content to the device in the subnet that promises to find the recipient. The gateway. The router.

How can the router deliver the message?
* Either it is in the same subnet as the destination
* or some device in the subnet(s) acts as a router towards the destination

The router has at least two network interfaces. It is a member of at least two subnets. It has different IP address in each subnet. The "WAN" subnet does not know that your router is member of 192.168.* subnet.

The 192.168.* subnets are private. It is forbidden to advertize that they exists. You home router hides the site A machines with network address translation.

Outsiders could access specific machine in the site A, if the router supports port forwarding. That too is network address translation, and the outsiders will think that they talk with (WAN IP of) the router.

 

[New_Tech]

If this is what you mean

Site A :
192.168.0.1 - default gateway
192.168.0.2
192.168.0.3
has public WAN IP a.b.c.d

Site B :
192.168.0.1 - default gateway
192.168.0.2
192.168.0.3 <--- running website
has public WAN IP w.x.y.z

machine 192.168.0.2 wants to visit website on site B 192.168.0.3?

in that sense, site A & site B are not on the same WAN.

Think of WAN IPs as phone numbers, private devices as handsets.

to visit machine 192.168.0.3 running the website, you have to give client machine in site A the WAN IP w.x.y.x, or a DDNS name and you have to do port (80, 443 or any ports you defined) forwarding on site B's router to machine 192.168.0.3

Okay, so as networking devices attach to another network (the WAN), they all get a WAN IP. Where does the WAN IP come from? Some kind of DHCP-like protocol?

 

[SamirD]

Okay, so as networking devices attach to another network (the WAN), they all get a WAN IP. Where does the WAN IP come from? Some kind of DHCP-like protocol?

WAN and LAN IPs come from the same place all IPs come from--God.

Okay, not really, lol. IPs are assigned either statically or dynamically, ie hard-coded or dynamically assigned by a dhcp server.

WAN IPs are typically assigned by an ISP via dhcp, but there can be other methods. LAN IPs are also typically assigned by a dhcp server, but like WAN IPs can also be assigned by other methods.

Coming back to the original statement told to you, there needs to be more details as what they said is only true with certain configurations.

You can have two different LANs connected to the same WAN, but being 'seen' by who? Someone on the LAN or from the WAN?

If two networks share the same default gateway IP and are connected to the same WAN, you ask about being ' called for by either network'--but who is calling who from where?

I think a diagram or a better description of the network would help. If the diagram mxnerd is the scenario you're thinking about, there are private and public IPs and network address translation which make that scenario work.

 

[IronWing]

My understanding of the question is that I have a home network, 192.168.x.x and my neighbor also has a network 192.168.x.x. We share an ISP. When I send a request to cornhub.com, how is that the returning packet isn’t sent to my neighbor instead of me.

The answer is that outgoing packets containing my request have to contain the network path back to my subnet. Cornhub.com doesn’t have to understand how my ISP allocated the IP addresses on its network; it only has to send a packet back to the ISP’s address and include the packet header from the request and let my ISP sort it out.

 

[New_Tech]

My understanding of the question is that I have a home network, 192.168.x.x and my neighbor also has a network 192.168.x.x. We share an ISP. When I send a request to cornhub.com, how is that the returning packet isn’t sent to my neighbor instead of me.

The answer is that outgoing packets containing my request have to contain the network path back to my subnet. Cornhub.com doesn’t have to understand how my ISP allocated the IP addresses on its network; it only has to send a packet back to the ISP’s address and include the packet header from the request and let my ISP sort it out.

You're right about all of that. The part I was missing was the part about what differentiates my path from my neighbor's. Thank god the ISP figured out how to do that so none of my corn preferences have been sent to any of my neighbors.

 

[New_Tech]

WAN and LAN IPs come from the same place all IPs come from--God.

Okay, not really, lol. IPs are assigned either statically or dynamically, ie hard-coded or dynamically assigned by a dhcp server.

WAN IPs are typically assigned by an ISP via dhcp, but there can be other methods. LAN IPs are also typically assigned by a dhcp server, but like WAN IPs can also be assigned by other methods.

Coming back to the original statement told to you, there needs to be more details as what they said is only true with certain configurations.

You can have two different LANs connected to the same WAN, but being 'seen' by who? Someone on the LAN or from the WAN?

If two networks share the same default gateway IP and are connected to the same WAN, you ask about being ' called for by either network'--but who is calling who from where?

I think a diagram or a better description of the network would help. If the diagram mxnerd is the scenario you're thinking about, there are private and public IPs and network address translation which make that scenario work.

The "who" in this case would be the recipient of my request be it a web server or ftp server etc. The part I was missing was the WAN assigning an IP (and in my eyes, stacking it on top of the other IPs for the querying device to build a complete path to and from) to the router that is unique to it upon adding it to the WAN in the area, lets say the street I live on.

I don't want to get too far off track here but is there a protocol that works like the stacking IP idea I wrote above? Maybe some kind of integration of all IPs into some other kind of code to create a full routing path to the querying device?

 

[mxnerd]

NAT Explained - Network Address Translation

How does NAT work?

Answer (1 of 4): Think of it like a library. A library allows us to borrow books we like to read and then after a time, we need to return them back for somebody else to borrow. NAT is like a library. Instead of having books though, this library lets us borrow Public IP addresses that are availabl...

www.quora.com

Most websites (with .com, .net, etc) got a fixed IP assigned by ISP using DNS system, only personal websites run by users at home will use some free DDNS service to do a subdomain to his own router's public WAN IP (usually dynamic) translation.

 

[mxnerd]

How DNS works.

 

[serpretetsky]

The part I was missing was the WAN assigning an IP (and in my eyes, stacking it on top of the other IPs for the querying device to build a complete path to and from) to the router that is unique to it upon adding it to the WAN in the area, lets say the street I live on.

To clarify, each network packet does not have a path, it simply has a destination and source ip address. Originally ipv4 was not envisioned to have duplicate ip addresses. All addresses would be unique, so that your scenario wouldn't exist.

Obviously your scenario is now very common (if not ubiqutous).
This is made possible by NAT (watch mxnerd's videos above). With NAT we can have private addresses that are only used inside your LAN. Public ips which are routed between ISPs are expected to be unique. Your router is constantly translating public ips to private ips.

Your ISP does not see any of what happens behind your router.Once the packet leaves your router all they see is a unique public ip address. It is up to the ISP to figure out how to route your packet from source to destination. There are various protocols that are used to figure out this path (Look up routing protocols).

 

[New_Tech]

This has been the best experience I've had on any technology forum. Thank you all for your help today. I will watch all of the videos provided and continue to develop my understanding of networking thanks to you all.

Many thanks,

New_Tech

 

[SamirD]

You're right about all of that. The part I was missing was the part about what differentiates my path from my neighbor's. Thank god the ISP figured out how to do that so none of my corn preferences have been sent to any of my neighbors.

That actually happens in the ISP router--it knows who sent what so it knows where to send the response. And let's say you and your neighbor both had routers connected to the ISP router, then it's basically the same principle--each router will determine where the packet came from on its respective network.

 

[SamirD]

The "who" in this case would be the recipient of my request be it a web server or ftp server etc. The part I was missing was the WAN assigning an IP (and in my eyes, stacking it on top of the other IPs for the querying device to build a complete path to and from) to the router that is unique to it upon adding it to the WAN in the area, lets say the street I live on.

I don't want to get too far off track here but is there a protocol that works like the stacking IP idea I wrote above? Maybe some kind of integration of all IPs into some other kind of code to create a full routing path to the querying device?

I don't know of any protocol that keeps the route information with the packet. And the main reason is space--you only have 1526 bytes in an Ethernet packet and you can't keep adding more info to it before you payload becomes just a small part of the whole communication:

More here:

Ethernet frame: definition and variants of the frame format

Ethernet frames carry data and are an essential component of data packets. But how exactly is an Ethernet frame structured and what variants of it are there?

www.ionos.com

 

[mv2devnull]

Carrying "full path" in every packet is a restrictive idea anyway.
* Lets say that London and Alamo are talking and there are multiple possible routes between them. Suddenly, a router on the chosen path goes down. That "full path" is no longer usable.
What actually happens is that the routers in between negotiate/select a new route and the talks continue. The routers will not rewrite all packets to record "full paths" in them.

* Lets expand on previous. You sit in London and there is a NAT router in Alamo. You tweet via the Alamo router. Twitter thinks that you are in Alamo.
Imagine that every packet would carry full path. Twitter would easily see "from the stack" that you are in London.


There is a "stack", a short one, in the router that does NAT.
When a packet goes "out", the router memorizes details about the packet and replaces source address with routers WAN IP.
When a packet comes "in" (WAN IP as destination) the router has to recognize that it is a reply to NATed packet and replace destination address with the memorized LAN IP.


Note: what (static or dynamic address) is separate from how (local config or DHCP).
For example, all my DHCP servers hand out predetermined, persistent, static addresses to hosts even though DHCP by default offers "next available address from a pool"

 

[ch33zw1z]

2 LAN's with the same default gateway connected to the same WAN is only possible with VLAN's. If you did it the legacy way (but still in use today), using subnetting, each subnet would need a default gateway in the subnet.

 

[New_Tech]

2 LAN's with the same default gateway connected to the same WAN is only possible with VLAN's. If you did it the legacy way (but still in use today), using subnetting, each subnet would need a default gateway in the subnet.

My question was more about two separate routers connected to the same WAN but I'm glad to know there's a way to do such a thing that you're talking about. I'm setting up a little project at home to get two computers (a VM with Ubuntu Server 16.04 and a Mac with a Java desktop program) to talk to each other. If I do end up putting this on the Internet to use as a test, I'll take a look into VLAN setups unless you know of another way to do this in a more contemporary way and with more security.

 

[ch33zw1z]

My question was more about two separate routers connected to the same WAN but I'm glad to know there's a way to do such a thing that you're talking about. I'm setting up a little project at home to get two computers (a VM with Ubuntu Server 16.04 and a Mac with a Java desktop program) to talk to each other. If I do end up putting this on the Internet to use as a test, I'll take a look into VLAN setups unless you know of another way to do this in a more contemporary way and with more security.

Ok, two separate routers == two separate LAN's

 

[SamirD]

My question was more about two separate routers connected to the same WAN but I'm glad to know there's a way to do such a thing that you're talking about. I'm setting up a little project at home to get two computers (a VM with Ubuntu Server 16.04 and a Mac with a Java desktop program) to talk to each other. If I do end up putting this on the Internet to use as a test, I'll take a look into VLAN setups unless you know of another way to do this in a more contemporary way and with more security.

You won't need vlans for that simple project. Just put them on the same lan and make sure the lan has internet access if you want them to have internet access. Think of vlans this way--virtual lans , ie physically separate lans. You wouldn't need that for two systems to connect to the internet.