What exactly happens "behind the scenes" when the "Gateway" box is checked, this is to say, how does the routing change across the mesh to route other remote mesh notes to the Internet connection on the router that has "Gateway" checked? I've looked at the route tables in all of my mesh nodes and I see no changes in the routing that would tell those remote mesh nodes how to route a call to www.google.com, for instance, across the mesh to the one node that has an Internet connection on its WAN and has the Gateway checked? What exactly is the man behind the curtain doing on the Internet-connected mesh router to propagate it's Internet connection routing to the rest of the mesh? I'm trying to fully understand how the routing changes when that box is checked as I am trying to build a non-Internet Internet...I want to place a "fake" Internet on the WAN port of the one router with Gateway checked to do some testing. So far it isn't working for me so I am clearly missing something in how the routing changes across the mesh when that magic "Gateway" box is checked. Thanks. 73, Bill, N4SV

What happens when the MESH GW checkbox is enabled, saved and rebooted is that the OLSR DYN GW module is enabled in the config files

The OLSR DYN GW module controls the injecting of a 0.0.0.0/0 HNA address

http://olsr.org/git/?p=olsrd.git;a=blob;f=lib/dyn_gw/README_DYN_GW is the main readme for the DYN_GW module.

The main item is that it performs a ping to the BBHN website (single ping) every 60 seconds with a fallback to Google as a safety net (the 4exact servers are listed in the source code.)

If any of the the pings are successful for a set amount of time than a HNA of 0.0.0.0/0 is published by the module (same feature that tells nodes about your local 'direct' subnet')

Once a HNA of 0.0.0.0/0 is published other nodes will see the route and add it to the routing tables on each field node in routing table 31 so they than can then get to the internet by going to the publishing node.

If the ping fails a set number of times the route is removed from publication and the nodes remove the 0.0.0.0/0 route from the table via that node thus changing the GW routing

A route of 0.0.0.0/0 means 'SEND EVERYTHING' to me. If the node is told to send all data but does not forward it onto the internet as a whole it WILL confuse the users if they are expecting to get out to the web and can't (depending how close they are to that filtering node vs the open node)

In addition if someone else turns on mesh GW and is closer they will not be able to get to your network on your WAN port so keep that in mind with your design and be sure to set the policies for your network.

I am noticing that when I enable WAN access, the mesh also has access to my LAN.

Isn't the a security and routing issue.  Multiple nodes could be using 192.168.0.x for example and create a IP conflict.

My setup is a Cisco router with sub interfaces to use my set of VLANs on a Cisco switch.  In this case VLAN 1 is the mesh WAN VLAN and my local LAN is a totally different VLAN and network. That way I can setup INBOUND and OUTBOUND Access control list on the  MESH VLAN and Network  to block access to and from the mesh, Internet and local lan.  The mesh has its own wan network on the router and certain access to the internet and not local LAN.  I have run into the same issues going from the LAN to the mesh. I never got into the firewall on the node yet. I can see having it there as not everyone is savvy enough to setup firewalls outside of the nodes. But there should be instructions as to how to remove, disable or bypass them as needed. Mike AE4ML

In looking over what is happening and what is wanted, Im thinking if you crank down the subnet on the mesh node WAN/route to only allow ONE IP might give what you want easily.

Try changing 255.255.255.0 to 255.255.255.254 on the node's WAN subnet mask and/or in the static route .

KTF

The technical implementation of the 'gateway' is such that if there is no route on the mesh to an IP address, then send traffic to the 'gateway'. Here's what this 'default' route looks like on the gateway node (there's more complexity with policy routing we'll ignore for the moment):

Destination      Gateway        Genmask      Flags Metric   Ref     Use   Iface

default          192.168.1.1      0.0.0.0       UG        0      0       0     eth0.1

Thus, any IP address that mesh traffic is being routed to, and the mesh has no specific routing definition, will go to 192.168.1.1. Changing the netmask to 255.255.255.254 for a 192.168.x.x route, bumps it to the default route.

All, please consider that this design and behavior is how all your home netgear, linksys, etc. routers work. The same scenario occurs when you connect 2 netgear devices back to back, for example:

Netgear_A_WAN_port -> Netgear_B_LAN_port/Netgear_B_WAN_port -> ISP_Internet_port

10.x.x.x_network -> 192.168.x.x_network -> internet

It is a design choice for the 10.x.x.x network to openly talk with the 192.168.x.x network (and venders' default is 'yes'). If the design choice is to not have access to the intermediate network, then a config setting can be made given know-how (on ether side of the fence). There are a few options for the intended behavior, DMZ, don't daisy chain, and more.

Joe AE6XE