The local AREDN node provides DNS to directly connected devices. The addressing scheme forces us to limit DHCP to 13 addresses (16 less 1 address each for the node, subnet, and broadcast).
With an additional router, you can certainly expand that to 254 devices in the 192.168.0.0/16 private address space (10.0.0.0/8 and 172.16.0.0/12 are reserved for the mesh itself).
Adding a LAN router to newtwork, or using NAT from the mesh node.
If for example I make my node operate as a NAT router as address 192.168.1.101,
other machines on my local network would use 192.168.1.1 for the GW to the outside.
I can add 192.168.1.101as my first DNS entry on some windows machines and that works with some success
on some machines on my LAN.
If my GW was .101 yes everything works fine.
I am trying to get my LAN that is Internet connected to also be able to drill through the node names for status page browsing on the mesh or mesh chat
I may even be describing my problem wrong
Kevin
You would need to add a static route in addition to the DNS to each PC (or to the router each PC is connected to if it supports it) to route 10.0.0.0/8 and 172.16.0.0/12 through the mesh node.
Things would be a lot easier if AREDN didn't use the DNS in such a non-standard way, with top-level zones like ".local.mesh" that don't exist in the "real" DNS. It's especially troublesome when you don't want to be forced to choose between having your computer on the mesh or on the "real" Internet at any given time.
Adding IPv6 support would also simplify addressing issues enormously by eliminating NATs and the port-forwarding nonsense that goes with them.
But why have two NICs on your computer when you really only need one?
A computer with two NICs is best used as a router so that your other computers only need one. (I set aside the special case of a computer with two different kinds of NICs where only one is generally used at any given time, e.g., one wired Ethernet and one WiFi.)
I understand the desire in some parts to keep the amateur mesh network completely separate from the Internet. Even if I agreed with this (which I don't), I must point out the need to carefully separate mechanism and policy. The former relates to what you can do; the latter to what you actually let it do. Unless you carefully keep them at arms length from each other, you can easily have the mechanism dictating policies to those who don't want them, and policies dictating mechanisms that can't be made to do what people really want them to do.
A classic example of a policy/mechanism debacle is the use of NATs as security firewalls. NAT was (and remains) a kludge to work around the short supply of IPv4 addresses and our inability to give all our computers their own public, routable IP addresses. Because of how NAT works, this godforsaken mechanism from the deepest pits of hell requires all sessions (TCP or UDP) to be initiated from behind the NAT by the computer with the private address, restricting it to function as a client only. There's no way to run a publicly accessible server on such a computer since there's no way to address it from the outside -- braindead workarounds like "port forwarding" notwithstanding.
But some misguided people see this buggy behavior as if it were a feature, specifically a security firewall. When you tell them that IPv6 can exterminate the NAT by giving every computer its own public address again, they protest that they don't want their computers to be reachable from the outside.
But nothing whatsoever requires that a computer using IPv6 to be totally open to the outside. It's still free to accept or reject incoming connections by their remote IP addresses. If you still believe in router firewalls (I don't, but you're free to differ), you can still have your router block incoming traffic to certain ports and/or certain local computers.
In other words, IPv6 lets you separate the mechanism from the policy. It doesn't force you to do anything, it simply gives you more options and freedom to choose what you want.
A post above showed how it could be done with a single NIC as have other posts when you have brought up these (or very similar) comments previously. Post have even gone as far to provide solutions to your personal network and how you could integrate fully into your existing environment all with just a single NIC.
I don't know of any easy way to do it with a single NIC that doesn't force all my Internet traffic to take an unnecessary loop through an underpowered embedded processor with an Ethernet port running at only 100 Mb/s. My cable modem regularly gives me 200-300 Mb/s; why should I have to sacrifice it just to follow your imposed architecture?
That's why I run OLSRD on my own Linux router, maggie.ka9q.net. It only has an Intel Atom CPU, but even it is substantially faster and has considerably more RAM than the Ubiquity unit up on my roof. It also has two gig-E interfaces vs a single 100 Mb/s interface.
My Mac laptop sends all its off-site traffic to maggie by default; if and only if it's headed for the mesh network, maggie will forward it up to the roof. Otherwise it goes straight out its other gig-E interface to the directly attached cable modem.
Maggie also collects OLSRD mesh network name advertisements and serves them locally through the name server I already use, keeping me from having to depend unnecessarily on the Ubiquti unit for yet another crucial network function.
"I don't know of any easy way to do it with a single NIC that doesn't force all my Internet traffic to take an unnecessary loop..."
This thread is about such a deployment.
As noted methods have been given before and to you, I'm not going to rehash them here again as this is starting to take this thread off where it doesn't need to go.
I wish you the best with your deployment as it seems you have some method you are happy enough with to not attempt to change it.
Well I got more than I bargained for with that question. Thank you for all the feedback it is really appreciated.
I suppose I will use my Amateur Radio Emergency Data Network setup for just that, an Emergency.
I will consider myself ahead of the game.
73
You've got a pretty typical use case really. I've got a node deployed at the local EOC and I'll be running it in NAT mode, it will have a 192.168.1.x address, and I'll add a route to each workstation to the 10.x network to point to the NAT node's LAN address. The services that the EOC workstations need to get to are cameras or a few known services - I'm not wanting every EOC workstation to be able to surf the status pages looking for things to click on.
Slightly off topic, but for an established network, you don't want to rely on the status page to show all of the services available. The status page is great for discovering capabilities as part of the experiment, or maybe gee whiz status stuff. But turning an emergency services person loose on it wouldn't work, and I doubt that even a non-mesh involved amateur would be able to figure it out.
Let us know how it goes...each situation is slightly different, and we all learn from each other's implementations!
By the way, this worked pretty awesome. I put the node at the EOC in NAT mode, turned off the DHCP server on the node, gave it a 192.168.0.250 address, then plugged it into the EOC LAN. I then went to the single workstation that we want to access the mesh and added a persistent route (route -p add) pointing 10.0.0.0 255.0.0.0 to 192.168.0.250. I created an icon on the desktop to the service I wanted exposed, and presto chango I'm integrated and happy. Plus the EOC IT guy is happy with me. Happy EM "customers" help pay for your ham radio gear!
Michael,
Thank you for the update on the node deployment success.
The problems that I run into with deploying nodes as NAT for individuals varies, even with a persistent static route and
even at times adding a static route to the users home router does not guarantee predictable success.
It seems like some browsers break the DNS searching and others do not. not enough testing to tell you why.
For me at home I have found that it is almost a guarantee that making the gateway on a PC be one of the nodes directly
fixes node DNS issues.
The problem is mostly exclusive to status page surfing.
I will try making removing NAT from my 6 nodes at home and see if any improvement is had.
Kevin
If using a home router to issue the DHCP address make sure that you have configured it to serve out the hostname of "local.mesh" into the DNS search list otherwise you have to always use FQDN (localnode.local.mesh instead of just "localnode"
Also it does depend on the home router, some will send a router redirect message which is ignored by some operating systems (iPhone -- they think its a security risk to honor router redirects) the home router needs to know that it needs to be a gateway device.
All these variables are why implementing into an existing network is considered an "advanced" topic, its so dependent upon the local network infrastructure, it helps to have a number of years in network design to do it.
The local AREDN node provides DNS to directly connected devices. The addressing scheme forces us to limit DHCP to 13 addresses (16 less 1 address each for the node, subnet, and broadcast).
With an additional router, you can certainly expand that to 254 devices in the 192.168.0.0/16 private address space (10.0.0.0/8 and 172.16.0.0/12 are reserved for the mesh itself).
Andre
Any PC on the LAN port can access the mesh node DNS servers which allows them to get to other systems by name.
If for example I make my node operate as a NAT router as address 192.168.1.101,
other machines on my local network would use 192.168.1.1 for the GW to the outside.
I can add 192.168.1.101as my first DNS entry on some windows machines and that works with some success
on some machines on my LAN.
If my GW was .101 yes everything works fine.
I am trying to get my LAN that is Internet connected to also be able to drill through the node names for status page browsing on the mesh or mesh chat
I may even be describing my problem wrong
Kevin
You would need to add a static route in addition to the DNS to each PC (or to the router each PC is connected to if it supports it) to route 10.0.0.0/8 and 172.16.0.0/12 through the mesh node.
Edit Note: Corrected subnet mask
I will try it ! thank you very much
Kevin
Adding IPv6 support would also simplify addressing issues enormously by eliminating NATs and the port-forwarding nonsense that goes with them.
If you have two NICs on your PC, Windows handles it just fine.
IPCONFIG looks like this on my PC:
But why have two NICs on your computer when you really only need one?
A computer with two NICs is best used as a router so that your other computers only need one. (I set aside the special case of a computer with two different kinds of NICs where only one is generally used at any given time, e.g., one wired Ethernet and one WiFi.)
I understand the desire in some parts to keep the amateur mesh network completely separate from the Internet. Even if I agreed with this (which I don't), I must point out the need to carefully separate mechanism and policy. The former relates to what you can do; the latter to what you actually let it do. Unless you carefully keep them at arms length from each other, you can easily have the mechanism dictating policies to those who don't want them, and policies dictating mechanisms that can't be made to do what people really want them to do.
A classic example of a policy/mechanism debacle is the use of NATs as security firewalls. NAT was (and remains) a kludge to work around the short supply of IPv4 addresses and our inability to give all our computers their own public, routable IP addresses. Because of how NAT works, this godforsaken mechanism from the deepest pits of hell requires all sessions (TCP or UDP) to be initiated from behind the NAT by the computer with the private address, restricting it to function as a client only. There's no way to run a publicly accessible server on such a computer since there's no way to address it from the outside -- braindead workarounds like "port forwarding" notwithstanding.
But some misguided people see this buggy behavior as if it were a feature, specifically a security firewall. When you tell them that IPv6 can exterminate the NAT by giving every computer its own public address again, they protest that they don't want their computers to be reachable from the outside.
But nothing whatsoever requires that a computer using IPv6 to be totally open to the outside. It's still free to accept or reject incoming connections by their remote IP addresses. If you still believe in router firewalls (I don't, but you're free to differ), you can still have your router block incoming traffic to certain ports and/or certain local computers.
In other words, IPv6 lets you separate the mechanism from the policy. It doesn't force you to do anything, it simply gives you more options and freedom to choose what you want.
I don't know of any easy way to do it with a single NIC that doesn't force all my Internet traffic to take an unnecessary loop through an underpowered embedded processor with an Ethernet port running at only 100 Mb/s. My cable modem regularly gives me 200-300 Mb/s; why should I have to sacrifice it just to follow your imposed architecture?
That's why I run OLSRD on my own Linux router, maggie.ka9q.net. It only has an Intel Atom CPU, but even it is substantially faster and has considerably more RAM than the Ubiquity unit up on my roof. It also has two gig-E interfaces vs a single 100 Mb/s interface.
My Mac laptop sends all its off-site traffic to maggie by default; if and only if it's headed for the mesh network, maggie will forward it up to the roof. Otherwise it goes straight out its other gig-E interface to the directly attached cable modem.
Maggie also collects OLSRD mesh network name advertisements and serves them locally through the name server I already use, keeping me from having to depend unnecessarily on the Ubiquti unit for yet another crucial network function.
This thread is about such a deployment.
As noted methods have been given before and to you, I'm not going to rehash them here again as this is starting to take this thread off where it doesn't need to go.
I wish you the best with your deployment as it seems you have some method you are happy enough with to not attempt to change it.
I suppose I will use my Amateur Radio Emergency Data Network setup for just that, an Emergency.
I will consider myself ahead of the game.
73
Slightly off topic, but for an established network, you don't want to rely on the status page to show all of the services available. The status page is great for discovering capabilities as part of the experiment, or maybe gee whiz status stuff. But turning an emergency services person loose on it wouldn't work, and I doubt that even a non-mesh involved amateur would be able to figure it out.
Let us know how it goes...each situation is slightly different, and we all learn from each other's implementations!
Michael,
Thank you for the update on the node deployment success.
The problems that I run into with deploying nodes as NAT for individuals varies, even with a persistent static route and
even at times adding a static route to the users home router does not guarantee predictable success.
It seems like some browsers break the DNS searching and others do not. not enough testing to tell you why.
For me at home I have found that it is almost a guarantee that making the gateway on a PC be one of the nodes directly
fixes node DNS issues.
The problem is mostly exclusive to status page surfing.
I will try making removing NAT from my 6 nodes at home and see if any improvement is had.
Kevin
Also it does depend on the home router, some will send a router redirect message which is ignored by some operating systems (iPhone -- they think its a security risk to honor router redirects) the home router needs to know that it needs to be a gateway device.
All these variables are why implementing into an existing network is considered an "advanced" topic, its so dependent upon the local network infrastructure, it helps to have a number of years in network design to do it.