a discussion has come up about use if the wan gateway feature. While there is general concern about allowing general traffic from the mesh to the Internet. There are also some specific advantages. One specific benefit is the ability to access the aredn site for software updates and packages. Thus the question has anyone tried tried using the openWRT firewall to create a rule set to allow outbound traffic to a specific site or sites?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
1) Part 97 prohibits the making of false or misleading statements over the radio. When you check the WAN GW features you are saying "I will route all traffic not destined for the mesh to its destination" if you now filter it later and only let very little traffic through (other than for reasons of Part 97 compliance) you have effectively in my opinion made a false statement over Amateur Radio.
2) Doing such action can break mesh routing if a service actually depends on internet access. There is no way in the system at this time to say "I only route small segments of the network" An example of this would be SIP based gateways from mesh nodes out to the internet to be routed into the existing PBX network. A node will route the packet to the NEAREST (defined by ETX) meshgw. If this meshgw is yourself and your blocking these connections you could effectively shut down a service that is expected to work on the network.
Firmware Updates: I see this moving over to Network management tools in the future. Not sure when or how, but I can forsee eventually the tools existing to update the mesh from a central computer (locally) and not be dependent upon the internet. Beyond that though firmware files are small and easily kept locally and uploaded. Package repo is where internet is more useful, but we are mostly phasing that out anyway and leaving it to small groups of packages. This means "dependency hell" where internet is useful to resolve will be less common.
Right now my personal recommendation is if a local network needs some internet access but not unlimited internet access I recommend using a proxy server. This will of course require more config on each individual PC to utilize however. This won't solve the node access problem at the moment since we don't support proxies in the code at this time however.
It seems to me that just checking the gateway box does not actually advertise anything to the other nodes (in the sense of "advertised services"). The other users have to go to the admin console of the gateway node to see that it is, in fact, a gateway. Even then, it just promises to be a gateway to some WAN and no guarantee that the WAN is the Internet. For example here we are building the MAIPN (Mid Atlantic IP Network) which will have various servers and services on it, but does not necessarily provide Internet connectivity). We plan to connect various local meshes to this backbone WAN. I believe other groups are doing something similar.
A gateway shows up on remote nodes on the remote node status page (assuming it doesn't have a local gateway already)
It also shows up on the OLSR Status.
In addition in newer versions it will also show up with "wan" on the mesh status page.
More important is not what shows up on the user interface (which is intentionally simple and does not display all sorts of complex information) but what is being told to the routing daemon (OLSR) in the backend is that "Route anything that you don't know how to get to to me I'll route it to the internet for you". Have to remember these are complex computers on the backend doing a lot of reaction for the users. Just because the user doesn't check the admin GUI doesn't mean that programming code has not relied upon what it has been told and what will be presented to users if they check.
Here is a bit more technical on how that "mesh gw" checkbox works (after a save and reboot)
1) The GW node reconfigures itself to permit traffic from MESH to WAN port and enables the "DYNAMIC INTERNET GATEWAY PLUGIN" for OLSR.
2) The GW Node routing daemon (OLSR) does an active check out the WAN port to be sure it actually has access to the internet by checking a group of internet only reachable servers (This is where the assert that its 'internet' and not just some 'wan')
3) Only after the routing daemon confirms it has internet access it begins tell other nodes about it by sending a 0.0.0.0/0 advertisement (default gateway -- aka "I am willing to accept packets to anywhere and get them to their destination"
4) Other nodes routing daemon (OLSR) begin relying on this assurance given in step 3 and will start routing packets towards that node
5) MeshGW node monitors to be sure it does have internet access and should it loose access it stops advertising that it is able to route packets.
Putting this another way. Filtering at the firewall after checking the MeshGW checkbox would be like joining the HF NTS traffic net, and accepting all the messages for that evening, and then throwing them away. I'm not sure if the NTS system can handle that by ignoring that person in the future (I assume so since it is people driven), but I can say the mesh can not, it has no recourse on 'ok let me route around that one person because they are not actually handling messages they say they will' it has to run by the numbers.of the mathematical calculations.
OK - good. If our backbone network has internet connectivity, the GW node will find it and start accepting that traffic. If the backbone has lots of inter-connectivity, but none to the Internet, will OLSR (etc) still find addresses on the backbone through some sort of broadcast/flood/whatever? (assuming of course that there is a routable path to the desired address). Or is some configuration required in the mesh node? The tunnel is a special case and I (think) know how to do that.
Or as a broader question: what are the guidelines for connecting a mesh onto a (non-internet) backbone network?
Trying to integrate backbone networks that are not part of the mesh really isn't that viable in 99.9% of cases (Clashing address space).
There is a feature request open for doing Mesh to WAN forwarding (similar to wan to LAN) that would give a method to access services on a backbone without making them part of the mesh that may solve some issues.
From the other standpoint non mesh backbones can be used currently with tunnels to route through the backbone to connect the mesh islands together without making them a part of the mesh itself.
I used the ambivalent term "connect" but I was leaning toward "interface" not "integrate".
Anyway - I understand that your answer to my question - about the preferred way one should connect mesh and backbone - is to use the tunnel feature.
I will be trying this soon - does the tunnel feature will still work even if the WAN has no internet connectivity?
My question is more along the lines of what is needed at the backbone (LAN/WAN) interface. I guess one requirement is a LAN-side DHCP server for the mesh gateway node. Port forwarding from the WAN to LAN on 5525 would be required at the server connection too. Does this sound right? Anything else?
Technically such a mesh would, in fact, be "autonomous" - yet dependent on the WAN - in the same way the mesh depends on any single-link radio path.
= = =
To pick up some resource that is out on the backbone somewhere, you would use a single-node mesh client with a dummy load for an antenna and plug that resource into the LAN port of the mesh device. Seems a bit silly, but that is a discussion for another time.
I'm getting a bit confused by your wan/lan usage here (for me LAN is the local network plugged into the ethernet port on the mesh node, MESH is wifi/dtdlink and WAN is the mesh node WAN port) and so I'm going to go ahead and break it out in a different manner just to make sure we are on the same page.
Mesh node CLIENT WAN port would be connected to this network that allows backbone access. IP address could be issued by a DHCP server or could be hard configured on the mesh node setup page for wan port
Another Mesh node would exist at the other end of the backbone to act as a server. It would be configured as above (static or DHCP). That node would need port 5525 towards its WAN port open (So if there is a router doing address translation or a firewall doing filtering like is the case of a home network connected to the internet then yes port 5525 forwarding would be needed)
You are correct, the routing and address space (which is really what I meant to speak about) would remain autonomous and function correctly but yes the link would be dependent upon the backbone working and being able to route the packet to its destination.
As noted currently the network isn't designed to think about utilizing the features of systems that are NOT on the mesh, the concept is its primarily designed to be resilient enough to work in an emergency, those systems that are 'outside' the mesh are somewhat presumed to 'not likely to be functioning in a real disaster" from a planning point but yes the feature request about MESH to WAN port forwarding if its implemented *MAY* solve that issue.
You have the WAN/LAN usage exactly as I had intended. Thanks. I do have one point of confusion - you say the WAN port can be assigned by DHCP or static but the web site says:
" The 802.1q switch and the AREDN nodes implement VLANs as follows:
VLAN1
I suppose you could go into one of the config files and assign a static address then?
Ok - for some reason I have a memory fragment that says in the case of UBNT it does not matter what you choose in the WAN pull down. You always get a DHCP client ... it would be good to confirm one way or the other.
I serious doubt that the FCC would consider advertising a default route when there is a firewall downstream as being a false or deceptive message in the context of Part 97.113(a.4).
However the part you might be concerned with is Part 97.113(a.5): If you're using the mesh to provide wireless internet service on a regular basis then that's likely going to be a concern, especially related to third party communications. To update your software of your mesh nodes, provide emergency communications, or link amateur radio repeaters? I'd say you'd stand up to strict scrutiny on that one, and I'd be happy to testify on your behalf!