I am sort of stumped on this.
My layout will be the following:
one subnet 192.168.0.0 255.255.255.0 whereas each computer on that subnet has 2 interfaces and it is statically assigned. GW will be a router with DHCP/DNS disabled at 192.168.0.254.
The second interface will have a subnet based on the last digit of the statically assigned first subnet whereas:
NIC1: 192.168.0.1 NIC2: 192.168.1.1 (255.255.255.0)
NIC1: 192.168.0.2 NIC2: 192.168.2.1 (255.255.255.0)
and so on.
On Nic2 will be running a software DHCP server.
My issue is this: I want all computers on all the NIC2 subnets to communicate to the master subnet of 192.168.0.X, and vice versa.
What is the best way to do this? Additionally the hardware MUST be configurable via REST or otherwise. So I cannot really hookup a router with static routes for each one of these because that's not really configurable programmatically. I CAN however use managed switches for this since CISCO makes a rather cheap managed switch that handles REST API requests.
I have considered bridging NIC 1 and NIC 2 but the issue is I would need to block DHCP packets from leaving the NIC 2 network. This doesn't seem possible with the limited windows network bridge.
Open to any suggestions!
Thanks,
Dan
Your best bet is to configure your gateway (router) with a static route from 192.168.1.0 to 192.168.2.0 and from 192.168.2.0 to 192.168.1.0. You don't say what kind of router you are using, but at least on Cisco, it IS possible to configure a static route via REST (as well as other ways). Refer to http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mapping/mapping_gd/layer3_examples.html#pgfId-1092835 .
There are 2 answers to this.
The first is what Herb said above which is to use Cisco smart switches and REST queries.
The second which is what I in the end implemented was to use a windows server environment with RRAS Lan-Lan routing. The details of which can be found here: https://onlize.wordpress.com/2012/08/18/lan-routing-on-windows-server-2008r2-step-by-step/
Related
I am a student learning computer network.
Here's how my network look like:
Router(NAT)
/ \
My PC My iPad
I have looked up my computer's routing table, and it shows the following:
$ netstat -r
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 172.22.128.1 UGScg en0
127.0.0.1 127.0.0.1 UH lo0
172.22.128.1 0:74:9c:96:72:55 UHLWIir en0 1200
172.22.161.13 ba:2e:b1:6f:69:39 UHLWI en0 740
I confirmed that the ip 172.22.161.13's gateway ba:2e:b1:6f:69:39 is the MAC address of my iPad.
I have a few doubts:
Shouldn't the routing table records ip address of next hop? how can it store a MAC address?
If the command netstat -r also lookups the arp table, how should it send packets to my iPad without going through the router?
The issue here is understanding the functionality of layer 2 and layer 3 in a network.
There is a difference between forwarding packets to the device located on the same subnet and on the device located on the different subnet.
I don't think there is a better definition of subnet, than devices that can communicate via a layer 2 protocol with each other. Routers are used to forward packets between devices in different subnets, that is, two devices in the same subnet do not communicate over the router, at least not over the "router" part of the router.
Devices that are located in the same subnet should be assigned the same IP prefix (i.e., the bits covered by network mask are the same). "Should" means that if it is not the case, then your network is configured wrong and may not work properly. This way your PC and your IPad can determine that they are on the same subnet and do not need to go over their default gateway.
Since your PC and your IPad are on the same subnet, they will talk to each other using layer 2. I am not sure from your configuration how many interfaces are actually wireless. If both interfaces are wireless, they may actually be capable of talking directly (i am not sure if wifi protocol in AP mode allows it, i think it does). If your PC is connected over Ethernet, then your Router also acts as a switch/bridge (which is layer 2 device) and forwards packets according to ethernet specification. You can learn about it by googling MAC learning.
This should answer the second question, now to the first one.
Actually, I wonder why the table is storing IP addresses. IP address of the next hop is not used in forwarding. First, note, that communication between devices which are two hops from layer 3 (i.e., routers) standpoint happens using layer 2. When a device makes routing decision, in takes the destination address from the IP header and looks up next hop, where what the device needs is a) outgoing interface b) how to reach next hop using layer 2 protocol of the interface. Then the device constructs an appropriate layer 2 header and sends the packet to the next hop device, which more or less does the same. So, actually your PC needs mac address of your router's interface to which it is connected to send the packet somewhere outside of the subnet.
I am trying to achieve double NAT working with UPNP. My PC connection is as follows:
Internet -> Router 1 -> Router 2-> PC
I have successfully done port forwarding on the Router 2, but not able to do on router 1. Due to which packets from the server(which is on Internet) are not able to reach PC.
Gone through few document how to tackle but mostly found manual way like bridge the network or put the lan wire.
I am rather looking for the some recursive solution using UPNP protocol to do the port forward on both routers. I guess torrent, skype does the same.
How to get the network interface related to router 1 and then port forward on that Network ?
Any help would be highly appreciated.
Thanks,
Pawan
There is an IGD-PCP IWF specification that tries to solve similar problem, although it assumes PCP support on your "Router 1", not UPnP. So let's try to approach this issue from a pure theoretical point of view with two plain UPnP routers/NAT devices.
There are several distinct steps of UPnP communication as per UPnP Device Architecture version 2.0:
addressing
discovery
description
control
eventing
presentation
Addressing is of little interest for us, let's assume proper DHCP everywhere and be done with it. Eventing and presentation are also almost useless in our case. So the main things to be concerned about are discovery, description and control.
Discovery works via SSDP message exchange. SSDP uses UDP for its transport with port number 1900 (by default) and well-known multicast address.
Description starts with URL provided by the device at discovery phase, the control point (that is PC in our case) needs to issue an HTTP GET request on this URL and that means it uses TCP as a transport protocol with devices IP address (unicast).
Control starts with URL provided by the device in its description, and it uses SOAP on top of HTTP on top of TCP which in turn also means unicast IP for us.
So, what all of that means for double NAT is that in description and control steps of UPnP interaction we have zero problems communicating from PC to Router 1 as all of that is just standard TCP with unicast IP addresses. But to get to the description step we need to have a URL of Router 1, so let's take a closer look at how this URL is acquired the normal way.
There are two main mechanisms for discovery — advertising (when the device periodically multicasts some information about it) and search (when the control point sends multicast search message and the device answers to that with unicast response). Obviously, by default our PC behind the Router 2 can't get multicast advertisements from Router 1 and the Router 1 can't get multicast search messages from PC, so we have a problem here and the question now is whether there is a possibility for communication without multicast.
Luckily, the same architecture document says:
In addition, a control point is allowed to unicast a discovery message to a specific IP address on port 1900 or on the port specified by the optional SEARCHPORT.UPNP.ORG header field (which supersedes port 1900 for this use), searching for a UPnP device or service at that specific IP address.
...
All devices shall listen to incoming unicast search messages on port 1900 or, if provided, the port number specified in the SEARCHPORT.UPNP.ORG header field and shall respond if any of their root devices, embedded devices or services matches the search criteria in the discovery message.
And this means that if you know the Router 1 IP address (from Router 2 side, of course), you can (and most importantly, allowed by specification to) communicate with it with unicast UDP messages and that is also NAT-friendly, so not an issue to be done from PC behind the Router 2.
The only thing left is getting Router 1 IP address. Unfortunately, there is no easy standard way to do that, but you have at least two options: tracerouting (in whatever fashion you want) and brute force IP scanning (most probably, the potential set of IPs for Router 1 is limited).
Now you can communicate with the Router 1, but there is still one minor thing you should always remember while communicating with it — in any internal UPnP messages you should use Router 2 IP address (as seen from Router 1 side) and its ports. Like in NewInternalClient parameter of AddPortMapping action on Router 1 you should use Router 2 IP. This, BTW, raises a question of Router 2 IP, but you can get that via Router 2 UPnP ExternalIPAddress variable of WANIPConnection service (this service is required for IGDs to implement).
So, to summarize:
this technically can be done, although I doubt that any standard library would do that for you
two things you need are:
Router 2 "external" IP and you get that via ExternalIPAddress variable of WANIPConnection UPnP service
Router 1 "internal" IP (from Router 2 side), that requires tracerouting or scanning
given Router 1 IP you just need to use unicast messaging at discovery step instead of multicast
everything else should just work, with only caveat of using Router 2 "external" IP instead of PCs IP in the UPnP messages
With the upnpc cli tool I've been able to get Double NAT port forwarding working.
For my example, let's say I want port 6667 to be forwarded to my machine, 192.168.50.123, behind a double NAT. The first layer of NAT has the IP range 192.168.1.1-255, and then 2nd layer has IP range 192.168.50.1-255.
On a machine inside the 2nd layer of NAT, just setup port forwarding with upnpc like normal.
$ upnpc -a 192.168.50.123 6667 6667 tcp
...
$ upnpc -l # this will confirm the rule is in place
...
Now for the slightly tricky part. I now issue UPNP requests to the outer layer NAT. Since the usual SSDP discovery won't work, I have to specify the XML root description URL manually. It's often something standard like http://192.168.1.1:5000/rootDesc.xml, though on some hardware the port number is randomized. I find just port scanning the gateway address will eventually reveal it.
Now that I have the rootDesc url, http://192.168.1.1:5000/rootDesc.xml, I then issue UPNP command to the outer layer NAT:
$ upnpc -u "http://192.168.1.1:5000/rootDesc.xml" -a 192.168.1.XX 6667 6667 tcp
...
$ upnpc -u "http://192.168.1.1:5000/rootDesc.xml" -l # this will confirm the rule is in place
...
With the -u option instead of discoverying the rootDesc, it just uses the URL provided.
The address 192.168.1.XX should be the 2nd layer network's IP address on as seen by the 1st network. When running the first set of UPNP commands this will be shown since it's the "external" address from that NAT's perspective.
With that now setup, traffic will go like this:
<INTERNET> --> MY_PUBLIC_IP -> 192.168.1.XX -> 192.168.50.123
We have two subnets
Router 1
192.168.2.1
255.255.254.0
Router 2
192.168.1.1
255.255.255.0
Modem >> switch
>> router1 wan port >> from lan port to switch >> Different computers
>> router2 wan port >> from lan port to switch >> Different computers
Please note two different static public ips(of same subnet) for both routers.
I would like to know how I can access a host from Router 1 to a host in Router 2 or vice-versa.
use a single router:
Modem >> router >> switch >> lan1 >> computers in lan1
>> lan2 >> computers in lan2
You don't even need two LANs formally, since the PCs don't need a special routing rule to reach all local systems in this case.
You use two address sets: 192.168.1.xxx and 192.168.2.xxx and a network mask of /23 or even /16, no difference there. This way all PCs know they can simply send out packages to everything inside 192.168... Whereas for packages outside they need a rule routing those packages through the router. The routing of packages between the two areas on the LAN side is done automatically by the switch. That is what a switch is build for.
This is an explanation of how you would do it assuming that you must keep these as two separate subnets!
That is, you'll have to set up access for each IP address in the other router's firewall, and then specify to which internal system it will connect.
Note: It's only safe to do this because you have two static IP addresses! There really isn't an easy, safe way to do this with dynamic IPs.
In that case, Router 1 will have to grant access to Router 2's public IP address and vice versa. How you do this completely dependent on the make and model of the router.
The routers will know how to route to each other, because they'll be using the public IPs.
So, the data path will be: System1 (subnet1)->Router1->Internet->Router2->System2
Since different routers have you specify addresses in different ways, make sure you know how yours expects you to input the address or range of addresses.
However, that's not enough. Because you have multiple systems on each subnet, all sharing the same public IP address, you also have to specify which inbound traffic goes to what subnet host.
That is, you start on System1 in the above data path. The data goes out Router1 and back into Router2. How does Router2 know where to send it? It only has ONE external IP address.
Again, there are different ways of doing this for different routers. On some, you can specify that data on certain ports gets sent to certain systems. (Port Forwarding)
Using Telnet as an example (you shouldn't! Telnet isn't secure. It's just easy to use as an example)...
You want to get from System1 (on subnet1) to System3 (subnet2).
On Router1 you specify that incoming data on Port 23 (Telnet port) should go to System1. On Router2 you send all Port 23 data to System3.
Port Forwarding, however, is somewhat limited insofar as, in the setup above, only System1 and System3 can receive Telnet data.
The other common way to do this is to have all data from a particular IP sent to one particular system on your subnet. That won't work for you, because you have multiple systems on each subnet!
I hope this isn't too non-specific! (Or too rambling! :-) ) I'm trying to be as non-specific as possible, but it makes it difficult to explain things! Unfortunately, since each company's routers use different interfaces, it's impossible for me to exactly what you need to do!
Let us know what your routers are. Then I can possibly be more specific.
In the meantime, however, look for the sections in your router to 1) the other router's data in, and 2) specify what data goes to which system on the subnet!
I hope this helps!
I am developing a networked application that runs on a few different computers on a LAN. One of the core needs is for the app to maintain a list of peers on the LAN with which it has communicated in the past, so that it can restore previous sessions. The naive solution would be to just remember the IP and store it in a table, but what happens when the IP of a peer changes?
Instead, I thought I'd store the hostname of the peers so even if the IP changes they will still be reachable via their hostname. (I know hostnames can change as well but that is good enough).
So my question is what exactly is needed to make hostname resolution work on a LAN with mixed Windows/Mac/Linux clients?
Without the use of a central authority the only reliable way to achieve this is through the use of zerconfiguration name resolution. This means that without a multicast router you will only be able to dynamically resolve peers on the same subnet as the resolving host. You could use something like bonjour for mac, netbios or ssdp for windows or avahi for linux but you can't assume that these are enabled. I may be overlooking some more popular protocols that perform this function well but I would personally throw together a quick udp broadcast name resolution protocol for your application. Take a look at these for some more ideas:
Zeroconf Name resolution
Universal local network name resolution method without DNS?
http://en.wikipedia.org/wiki/Zero_configuration_networking#Name_resolution
http://en.wikipedia.org/wiki/Broadcast_address#IP_networking
I would pick a specific udp port to listen on (lets say 12000) and then when you're ready to resolve hosts send a "hello" udp packet out to 255.255.255.255 on port 12000 and all of the other hosts on your network running your app should reply with a packet containing their hostname, possibly other information.
What are the effects of incorrectly setting the netmask? I have a C++ application that sets the network mask of a device. If the netmask is set incorrectly, tftp doesn't seem to work properly. Why would this happen? What other problems occur when the netmask is not properly set for a device/PC?
While this question is probably more about IP networks than programming it is a challenging subject for many developers.
The netmask delimits the host address (your PC or server) and the network address (the part of the logical network infrastructure in which your system lives). The two parts are used to deliver the data packet to the correct device. The network address is obtained by ANDing the netmask with the IP Address. Consider the following scenario:
IP Address: 10.0.1.1
Netmask: 255.255.0.0
The host address portion of the IP address for our PC is 1.1, so the PC knows that any host addresses starting 10.0. are local to it. Any addresses that then start 10.1, etc, are not 'local' and will need to be forwarded to a router. If you have another device intended to be on the same network that is:
IP Address: 10.0.2.1
Netmask: 255.255.255.0
Here the netmask is wrong for our example setup, this device is now going to see the network address as 10.0.2 and the host address as 1, if it tries to communicate with 10.0.1.1 it will see a network address of 10.0.1! Not local and so will refer it to the default router for forwarding. If the netmask was correctly set (i.e. the same as the first example, assuming that's the correct setting for your network) then the second device would see the first as local, i.e. on the 10.0 network and wouldn't attempt to forward the packet to a router.
Many protocols will happily cope with this but tftp is intended to operate within a single network and so will fail as there's a perception that the target is on a different network.
This may not describe your exact situation but I hope that the example demonstrates the important principle that configuration matters, you can't have an inaccurately configured environment and expect it to work.
The netmask determines which IP adresses are local (non-routed); IP adresses outside that range go through the router. If the netmask is wrong, the program tries to directly access sites where it has to go through the router, or vice versa.
The netmask defines, which part of the IP-address is used as address for the network and which part is used for the workstations.
First Example:
IP1: 192.168.20.4
IP2: 192.168.192.4
NM: 255.255.0.0
Both IPs are in the same net. They can communicate with each other without needing a router. That's because the IP-addresses will result in the same bitmask when you or it with the netmask.
Second Example:
IP1: 192.168.20.4
IP2: 192.168.192.4
NM: 255.255.128.0
Now both IPs are in different networks because when you or the IP-addresses with the Netmask, the resulting bitmask will be different and they wont be able to communicate with each other without a router that routes between the two networks.
You can test this by yourself with ipcalc.
Possible implications of mismatched netmask are explained here. In short:
The host is likely to construct routing table incorrectly.
The host will miss some broadcast packets and not send broadcasts properly.
Mis-function of TFTP is almost for sure caused by the first reason. It affects any other IP protocol in the same way.
Other answers mention only the first problem (which is OK, as the second one is rather marginal). Note that it is not the netmask of the interface itself which determines how the IP packets would be routed - it is the routing subsystem of the host; but the netmask is normally used for constructing the routing table.