KG6JEI

We always encourage hams to follow RFC, but in the end it´s up to everyone to decide what fits into their existing IP -plan. In this case it´s of no big issue since the IP´s will never be exposed to the Internet, only through the tunnel.

Also here, with my ISP, this particular IP network is not routed outside by them. And from what I understand this IP network is used isolated by Google to perform certain scientific tests.

But, once again. We encourage hams to follow RFC for private address-spaces suitable fo their needs.

I'm not sure you can guarantee that.

As I noted we do not filter on the mesh nodes the 1.1.1.0/24 network. (Nor do I believe we should as it's a public network that could be put into service)

I can speak for myself and say in my current network setup leakage is 100% possible.  Even with my Checkpoint/Palo Alto/Cisco/Custom firewalls in line 1.1.1.0/24 doesn't appear to be in my bogon lists by quick glance (likely because it is technically allocated)

Every mesh node advertises it's VPN IP address as one of it's IP's.  This shows up in links on various pages of the BBHN/OLSR UI.

An example leakage possibility:

If the route goes down all of a sudden the fallback would be to send the packet out the nearest WAN GW. This by definition is leakage by crossing the bearer from BBHN to Local "WAN" network. Most home routers will likely not block it and on corporate routers it's not suppose to be blocked either. This causes further leakage into the routed internet.

Here is what happened in the past:
"While network 1.0.0.0/8 was an unallocated and unadvertised network any such traffic directed to an address in this block that “leaked” into the public Internet would follow a “default” routing path to the point where there was a “default-free” routing element, where the traffic would be discarded.  As soon as any such address in 1.0.0.0/8 was advertised as reachable into the public Internet, instead of being discarded as the boundary of the default-free zone (DFZ), the packets would be passed onto the destination rather than being discarded."

As seen once they advertised it it was routed. Also I notice you have a USA tunnel, can you guarantee that persons ISP won't route it ? How about every other node on that users mesh and their ISP's ? What about nodes that VPN into a node that's connected via rf to another node to another to one on the tunnel?  As you can see this very quickly becomes a can of worms that becomes hard without positive control over 100% of the nodes in the system.

Will it physically harm anyone, no, has it caused APNIC to declare space unusable,for the time being yes, will it likely be a lot of leaked traffic, no-but  a lot of small traffic adds up to 800mbps spikes.

And yes I believe Google was brought in for some capacity based on that doc to help test, what they are/were testing I don't know, but if APNIC told them to do something then it's within APNICS's authority to do so as the allocating authority (I see the advert is currently associated to Google under their AS15169 in the BGP tables: http://bgp.he.net/AS15169#_prefixes ). Google does make sense in a lot of regards due to their number of peering points, get the data off the 'uncontrolled' net as quickly as possible and into the 'controlled' infrastructure where it can be accounted for sooner reducing the chances of some router blocking it giving false readings.

**note: not intended to be a fight, just trying to point out why I am concerned about this as a networking person who has spent a fair amount of time with the BBHN code, and why in a global project like this some assumptions that have been made can't be made and why we should avoid this from the start rather than risk issues in 5 years.

Well, I agree with you partly, but it´s a small issue to address by the means of some extra code to implement as a failsafe to ensure that 1.1.1.0/24, 1.2.3.0/24 and so on, never reaches the WAN or RF interfaces of the nodes.

This is something that I can implement rather quickly and will do so during next week.

Our GRE solution is implemented in a "package" like way, so this extra code will be part of future releases. The rather small footprint of this solution gives us the benefit of having som more addendum of different features without growing significantly in code. For example, we have already implemented the UCSD ripd connection for anyone wanting to use it. It´s still small enough to be harboured in the GL model though :)

As I said before, the recomendation is to use RFC private address-spaces, but I see this addition of code as a failsafe.

You would need that block on 100% of the nodes in the mesh network, not just the gateway nodes. In otherwords it would have to be in mainline. I'm not sure I see that happening, I know I would personally oppose such a patch on the grounds it interferes with global internet routing.

Every node will need to see the IP address as part of the routing table method for how OLSRD works it goes out in the MID packets (and it has to be in them) to advertise route paths.

Every node on the network can connect to the WAN and would possibly forward the packet out to the WAN this is why the block would have to be on 100% of the nodes and not just the GW nodes.

Unless your planning on heavily modifying OLSRD to have each node remove some of the data (and I'm not sure how much that would confuse the daemon off hand if one node knows the route fully and the others don't)

I have two scripts now to support vtund.
1) installs vtund server.
2) installs vtund client.

I do have to stop the firewall on the server to allow connections to occur.
Any suggestions on how to determine which firewall rule is blocking the vtund packets?

Also, if anyone is running vtund SERVER with multiple client connections (I suppose the dev team is doing this), can you share your config files on how you did this (ie.  tun0, tun1, tun2, etc)?

My tunnel scripts and tunnels are working well finally!

I even added the following into the /usr/local/bin/linkled script loop to indicate when tunnel connections are active:

...
if ifconfig|grep tun > /dev/null 2>&1; then
  echo 1 > /sys/class/leds/ubnt:orange:link2/brightness
else
  echo 0 > /sys/class/leds/ubnt:orange:link2/brightness
fi
...

This turns on the ORANGE led on my BulletM2 when a tunnel interface is active!

Here's what I'm working on next....

If you are going to programs GUI it's likely better to go ahead and go above and beyond the original instructions which made VERY poor use of address space by only assigning 1 tunnel from every /24 and actually take it down to use /30's  that means instead of only having 2^8 networks we could have 2^14 networks which allows much less chances of conflicts.

Good point.  It's been a few years since my network calculation days... but here goes...

If we want to stay away from the non-routable class A (10.x.x.x) network, then the next logical would be a class B (172.16-31.x.x).  We could still use a netmask of 255.255.255.252 to get the /30.

If my math is correct:

[12bits] - [18bits]              - [2bits hosts]
[ fixed ] - [server assigned] - [fixed (253=client, 254=server)]

This way, everything that is tunneled will be on the 172.16.0.0-172.31.255.255 network space.  This would give us 2^18 networks.

Am I thinking through this properly?

Keep to 172.31.* (VPN space based on the previous document)

use /30 assignments on all the below IP address for client/server 

aka

SERVER.    CLIENT.     NETWORK      BROADCAST 

172.31.1.1   172.31.1.2    172.31.1.0    172.31.1.4

172.31.1.6   172.31.1.7  172.31.1.5    172.31.1.8

172.31.1.10   172.31.1.11    172.31.1.9    172.31.1.12

So on and so forth untill you use all up in 172.31.0.0-172.31.255.255

this is where you get the 2^14 networks as it's 2^16 wide but each tunnel needs 2^2 IP's  (sorry I said 2^18 before put my math the wrong direction) 

Note: I say keep to 172.31.* as we previously an published that as VPN space and we may some day need the rest of 172 for other reasons. We already use part of it for NAT mode hosts so we don't want to trample on that.

got it.

I think you meant:

SERVER.    CLIENT.     NETWORK      BROADCAST

172.31.1.1   172.31.1.2    172.31.1.0    172.31.1.3

172.31.1.5   172.31.1.6  172.31.1.4    172.31.1.7

172.31.1.9   172.31.1.10    172.31.1.8    172.31.1.11

Would you believe me if I said I was just testing your subnetting skills? I Didn't think so....

Your numbers would be correct yes and what I meant to put up, good catch.

So, In order to make this simple for the user...

I propose the following algorithm to determine the network number...

first octet is always 172
second octet is always 31

third and fourth octets are derived:

Take the MAC address 3rd octet and rotate right 2 times,
then flip the bit order (ie. 00000001 becomes 10000000)

Then take the MAC address 4th octet (which is "most unique")

third octet of the vtun becomes MAC 4th octet
forth octet of the vtun becomes the MAC (rotated and flipped) 3rd octet.

This should mean that we always have the last two bits cleared due to the rotate right x2 and to be used for the 2 host entries plus broadcast address.
Then, each vtun client entry, gets the "next 4" group of addresses.

Make sense?

MAC: 11:22:33:44:55:66

Octet 3 would only change when vendors change (100% of Ubiquiti share the octet already) would think you would want to use octet 6 for ip octet 3 and octet 5 (rotated and flipped) for ip octet 4 base.

Another problem: how do you intend to get the CLIENT mac address to the server for setting up easily (would need to use client side as server side will be less unique as it will host several tunnels) ? Post it on the UI and tell the user to give this to the other end? Would this be considered burdensome by users to do? Is it less burdensome than the alternatives ? 

This methoud would mean a client could only connect to one tunnel master (no redundancy in tunnels) because the client IP needs to be UNIQUE across the mesh.

While I like the idea of making things easier, and I like the thought of reusing what we already doing, I wonder if tunnels (something that is suppose to have user interaction to setup as apposed to dtdlink which is suppose to work out of the box) is the right place to automate or if we should leave IP assignment to the tunnel master admin.... Though that brings it's own issues. 

I don't think I can give a flat out answer on it at this moment as to what I would suggest without the deeper thought to the rest of the setup. The method prescribed is not without potential just needs some gaps filled in to better understand I think. 

yes.  Octet 5 and 6 are what I intended.

I'm totally open to discussion on how best implement this...

Also, the vtun server is where the network assignment calculations are done.  The client will simply enter their assigned number on their end.  The network numbers would always be based on the serving node's MAC address and order of entry of how many clients are defined to connect.

on the client, we can calculate the required addresses based on the "network number" assigned by the server.  (server ip, client ip, broadcast address, and network numbers).

I'm envisioning the interaction would flow as follows:

client12 asks to connect to server53

server53 creates a "client" entry for client12, assigns a pwd, and gets a "generated" network number based on server53's mac and how many clients he has already defined. (MAC + every 4)

server53 then sends client12 that information via email, phone, CW, winlink, packet, Dstar slow-data, etc... ;-)

client12 creates a "server" entry on his node and specifies the host, port, pwd, and network number.

Another question regarding OLSRD and routing... aren't the vtun addresses "172.31.x.x" simply point to point?  Ie. they shouldn't be visible from other nodes on the mesh, right?

D.

and wow.  looks like I may need to start a new thread for the Virtual Tunnel UI work...  this one is getting long!

Ah ok, that makes a bit more sense now.

Only downside I see is that if you change the central node you have to reconfigure all the clients.

We have a potential IP conflict issue but that is overall going to be very minor I think in this case. and should work.

I wonder If we want to consider the following:

1) Switch from TUN to TAP interfaces (its no longer a PtP its a Broadcastable link which means we don't need to put a 'broadcast' address in olsrd config, only the interface name

--- This does have a downside of a bit more traffic may be generated over the link, but should be minimal.

2) Run a DHCP server on the server node, and use a DHCP Client on the client node to obtain ip address -- This lets us get around IP address changes when the main node gets replaced.

I've done this once in the past to make client side easier, than all they would need to know is the user/password combo.  it adds a fair bit more complexity however to the server side. 

Its a judgment call, is the extra use of resources worth the ease of configuration for users. I welcome input on that subject. I'm not pushing one way or the other, now that I understand the IP is based off server side it makes more sense to me what you are suggesting and it is certainly viable.

As for IP addresses:  OLSRD advertises any link it runs over in its packets, so the whole mesh knows about the PtP link IP address and puts it in its routing tables. If two nodes share the same IP in a mesh the program will think that  they are the same node and you can end up with a split brain routing problem if I recall correctly.

Jim: May be time to pull this under Developers forum as its really evolved into a development discussion.

Regarding ease of changing nodes...

I could make the UI "suggest" the IP by default, but, allow the user to change it if they want.  This way the server "admin" can decide to change nodes at will.  They just need to override the network numbers 172.31.x.x on the new server node. 

No client changes would be required with this approach.

D.

Works for me.