Hi Ron, here in Barrie we also started off using v1.0.0 firmware for GRE tunneling. And yes, if the tunnel comes up properly you should see the node names from the far end of the tunnel on your Mesh Status screen. Note that the "status: up" for tun1 on the OLSR screen doesn't mean that the tunnel is "operational". It only means that the tunnel (tun1) was configured properly in that node and the tunnel is capable of coming up. If the nodes at both ends of the tunnel show "status: up" but no nodes are displayed on the Mesh Status screen after 5 minutes; check your DynDNS account to see what was entered by the scripts when they were executed. You can enter an incorrect IP in DynDNS for each node and then reboot it, the IP should be corrected by the scripts when they are run.

Some other problems we experienced here in Barrie:

1. The octal (chmod value) had not been set properly for the different script files. 
2. The internet router had not been configured properly to pass port 1723 and to allow PPTP protocol 47 traffic. 
3. Errors in properly entering the 2 new lines needed in crontabs/root. 
4. Didn't reverse the two tunnel IP's in the ifconfig lines at the far end of the tunnel. 

Hope this info helps. 73

A very quick way of checking that the tunnel is OK is by pinging the remote end pointopoint IP from your own node in CLI mode.

Ie, login to your node using SSH and issue the command 'ping x.x.x.x' without quotes and the x.x.x.x representing the remote end pointopoint IP.

I'm still confused and need help with explaining what subnet mask to use in our Internet routers. Al-VE3RRD mentions that his router issued his mesh an IP 192.168.2.36 subnet mask 255.255.255.0. This means that the router is issuing IPs in range of one class C network: #2 (X.X.2.X). So how is traffic on the tunnel IP 192.168.80.1 & 192.168.80.2 get routed out of the Internet router when it's on a different class C network: X.X.80.X. The Internet router is only going to handle traffic on it's own X.X.2.X. network. Hence, why I thought the Internet router's subnet mask needed to be changed to 255.255.0.0 to handle this. Johan's document makes no mention of what IP his Internet router is issuing, only that it's a  static IP,  so I couldn't determine if his Wan IP is the located on the same tunnel class C network of X.X.1.X.

Or should  I make the deduction that GRE 47 protocol handles this?

We've also downgraded our tunnel routers to V0.43 and unfortunately, one got bricked during the downgrade. Luckily we had a spare at the other and and got it configured. Thanks for being patient during my learning curve.

Hi Ron, like I said, I'm no expert but my understanding of how the tunneling scripts work is like this:

I could start by saying that my computer I'm typing this on has an IP (from my internet router) of 192.168.2.15 - so how can I be on the "internet" with this IP?

Take a look at my document in the S51tun file for ve3rrd-shack. This node is configured for 3 separate tunnels and in the section called # IP handling, there are several variables which are used to store the IP's (both public and LAN). For example ip0 stores the IP for port eth0.1 which is the WAN port of the mesh node (and in my case will have an IP of 192.168.2.36 /24). Variable ip1 stores the public/external IP for node ve3rrd-portable1 (which was obtained from my DynDNS account).

Now if you look at the section # Tunnel to ve3rrd-portable1.ham-radio-op.net, the first line adds tun1 with a local (node WAN port) IP of variable ip0 and a remote (external/public) IP of variable ip1.

So the IP's used in the node (192.168.70.1, 192.168.80.1 etc) are only to keep track of things inside the node, and the IP's used by my internet router (192.168.2.36, 192.168.2.15 etc) and only to keep track of things inside the internet router. The tun1, tun2 etc. GRE tunnel connections (via port 1723) are from my internet router's external/public IP to the external/public IP of the node at the other end.

Hope I got that correct. 73

Hi Ron, One other statement that I should have added to the end of my last post was that it is the port number (1723) that is important and must remain the same from one end of the tunnel to the other, even though the IP's can change as the tunnel passes through routers etc.

If you want to try something that is very useful when getting your mesh network tunneling operational; try forwarding ports 8080 and 1978 inside the meshnode. On the Setup/Port Forwarding screen, setup port forwarding for Interface:Both, Type:Both, Outside Port:8080, LAN IP:localnode, LAN Port:8080.

Now you can be anywhere (even in a Tim Hortons) and access your node via this "internet back door" by using the URL from DynDNS port 8080. If you know the node password you can even access the Setup screen and reboot the node.

If you also do port forwarding (to localnode) on port 1978, then you can also see the OLSR screen. Again use the DynDNS URL with port "1978/all".

73

Ron,

The IP addresses for tunneling has nothing to do with the other interfaces except that it will be internally routed through the mesh and through the GRE tunnel.

Seen from a routing perspective you actually must use IP addresses on different subnets to make routing work.

Really makes sense Johan, thanks. I, know nothing about VPN, and a bit about networking, so I got confused with the different Class C IPs used for the tunneling. Hence, I why I need to read up on GRE protocol and VPN.

At the moment, both routers are still not pinging the other Tunnel IP (192.168.80.1) on one and (192.168.80.2) on the other. I've been running parts of the scripts manually on both mesh routers which deal with assigning and checking IPs within the mesh router and with the IP check at millhill.org server.

Both mesh routers are properly configured, as far as I can tell, responding with the proper IPs on the right Interfaces. The WAN IPs on both mesh routers are updating the DynDNS server correctly after 5 minutes, when I manually put an incorrect IP in DynDNS. So that works fine.

The next thing I will focus on is both Internet router Firewalls. I will be putting both mesh router IPs in the DMZ of the Internet router and see how they react. Hopefully, it's just one or both routers blocking GRE or Port 1723.

Looking at the log files on my Internet router (Internet Sessions) I can see my router sending out a GRE request from my DHCP assigned WAN IP of the mesh router (192.168.1.101) to the outside WAN IP of the remote Internet router (which is listed correctly on DynDNS server). I see nothing in the System Activity log file accept for the mesh DHCP IP assignment.

Next item, to check the logs of the remote Internet router to see what's happening there.

My tunnel is up and running. I could ping the local & remote tunnel IP (192.168.80.1 & 80.2) on both routers. Thanks for all your help.

I am moving the following question to another forum, realizing that it's not a VPN issue.

"The remote router is properly resolving the IP addresses however, mine doesn't. All I get is IP address in the current neighbours, nothing listed in the remote nodes. The remote node lists my node properly in both sections. I've checked the resolv.conf file on both and both are identical accept for the Internet gateway IP, which list our own gateway.

My question is what could effect my router from properly resolving the IP addresses?"