We have our Providence, RI network working well with RF throughout the city however we need to tunnel back to my device for VoIP and so on. The issue is the hospital network is also a 10.xxx.xxx.xxx and the NanoStation will not connect. I have the DHCP checked rebooted several times...no connection. It's difficult explaining to the network administrator because as he provided a working internet port and it is working when he connects his laptop and it reaches out to the internet.
If I go there what would I do to correct it?
We updated the firmware using a hotspot and of course it connected to the tunnel fine so I'm guessing IP conflict? The Network Admin doesn't think so because he has connect others to his network in the same way.
Am I doing something wrong?
Denis
Inside the AREDN node, between the WLAN/LAN of the mesh node and the WAN port, there is basically a NAT function. AREDN uses all of the 10.x.x.x network. You cannot NAT from a 10.x.x.x network to another 10.x.x.x network, so the node cannot work with a 10.x.x.x address on the WAN port.
I have gotten around this issue by using a a double-NAT approach and some intermediate network with a non-10 numbering range. You have to put in port forwarding for each path through this interface so it is limited, but it does work.
Ken
I see that changing it to NAT gives it a 172.1.xx.xx address, will we still see my other connected over the air nodes? What are the limitations? Can you suggest how to port forward and to where? Do I need to get a port from the Hospital IS?
This is above my pay grade for sure. I have been trying to get this tunnel for over 3 years and did not expect this and I am very sure that this is not the only time this has or will happen as this is very common with business VPN's.
Thank you
Denis
The connection is done by adding a simple router in the path between the two 10 - networks. The router translates requests to an intermediate isolated network such as 172.186.x.y (where you can pick any number for x and y from 2 to 254).
The WAN port of the added router sits on the hospital 10 network and gets an address from them via DHCP - or their network administrator will tell you what to use and you set at static IP to match. Static is a good idea anyway.
On the LAN side of the added router you specify the 172.168.x.y network numbers you want to use. The router's LAN side address will be 172.168.x.1 and will be the gateway for for the mesh nodes.
Whatever mesh node you are going to plug into this router should have a WAN static address on the 172.168.x.y network. The LAN configuration of the mesh node is just the standard 5 host Direct or similar. (For a quick start you could specify DHCP for the mesh WAN setup and change it to static once its working - make sure DHCP server is enabled on the added router). Static is desirable because you want a fixed IP for the port forwarding (next).
Each node wired to the added router is reached at the *same* address of the hospital network, but at a different port. For each node you want to see from the hospital side, you need a port forward entry in the added router's configuration. You port forward to the WAN address of the mesh node. You use a destination port of 8080 for the GUI. This lets you see the status of *all* your mesh nodes and do setup on those nodes that are wired to the added router.
You access services on the wired nodes by specifying the appropriate port forward(s) in the new router and a matching incoming port forward(s) in the mesh node.
To access services on nodes that are connected by RF only - from the hospital LAN - requires port forwarding instructions in the mesh nodes themselves ... this is something I cannot help you with. Depending on the application, it may be possible to have a server connected to the wired node that communicates via RF to all the mesh nodes and talks to the added router through that wired node (file server PBX whatever would be located at the wired node).
One more thing: to avoid an RFC1918 error message in the wired nodes, you need to go into /etc/config.mesh/ and turn off the RFC1918 filter by setting it to a zero. You need to do a "save settings" function in the setup menu for this to become effective. If you update the firmware, this change will need to be done again.
I am sure the developer-guru's will correct me if I said something wrong here ... and corrections are welcome.
Ken
Thank you Ken! Looks like I have my work cut out for me here! Your instructions are very good and I couldn't appreciate it more! I'm not afraid to say I will need help with this configuration but I have been deep into other devices like this and made it out alive!
I let you know!
Thank you again!
Denis