Re: [B.A.T.M.A.N.] Problems connecting VPN and WLAN with Batman-adv

[Clemens John <clemens-john@gmx.de>]

[-- Attachment #1: Type: Text/Plain, Size: 3788 bytes --]

On Friday 02 April 2010 13:50:32 Linus Lüssing wrote:
> > I use Fonera and Dlink Dir300 wich have a atheros chip inside.
> 
> Ah, great, those Dlink routers are the ones I'm using here too :).

hehe

> > Yes the vpn network is created over lan.
> > The VPN is created by an central openvpn server in tap mode and ping
> > inside the vpn works without batman.
> > The VPN is used to connect several mesh clouds which can´t sea each other
> > wireless.
> > Ping from one Mesh device to another meshdevice on the other side of the
> > vpn tunnel works. I think because they are both in the 10.18.1.0/24
> > network.
> > 
> > But the devices which are connected to the vpn network have a ip from
> > 10.18.0.0/24 and should also be reachable from the 10.18.1.0/24 (wlan)
> > network and this doesnt work so far.
> 
> Yes, you're right, if a host has a /24 subnet and wants to be able
> to reach another host on a different /24 subnet, then they need an
> extra (default) route entry in their routing table. In your setup,
> why aren't you just using a /16 subnet instead if you want them to
> reach each other over direct links without any routing?

I don´t exactly know why we are using different subnets, because I´m not verry 
familiar with networks.
But I think it is, because we have different projects in our network with 
different vpn/24 subnets and wlan/24 subnets which should all be able to be 
connected to a bigger network.
Olsr did this routing entrys by default I think. What can I do to make batman 
do this automatically too or is this just completely the wrong way?

How are you doing this and how is this done in other networks?

> > I can ping the mac adresses inside the vpn from the wlan network with
> > batctl but not with normal ipv4 ping.
> > 
> > > From the configuration now, it looks like you're having another
> > > batman-adv on the other side of the vpn as you've assigned tap0 to
> > > batman. So keep in mind that the recipient on the other side of the
> > > tunnel will get batman-adv ethernet frames only which encapsulate the
> > > payload - there has to be a batman-adv on the other side to unwrap the
> > > IP packets again.
> > > And if there is a batman-adv on the other side of the tunnel, make
> > > sure the vpn itself is transporting whole ethernet frames and not
> > > only ip packets (in tinc this is "switched" mode for instance or
> > > in OpenVPN having "dev tap" and not "dev tun").
> > 
> > Yes the setup is like you describe it.
> 
> Ups, ok, sooo, you want the complex stuff :)? Just want to note,
> that this has not extensively been tested yet, I had just tried it
> here with a friend and this test for one tunnel worked unexpectetly
> good. However, we don't know yet if there might occure some
> undesired things in larger scales. But if you are up to an
> adventure and want to share your experiences with this, great :).
> 
> I think I'll better write a little description and article in our
> wiki about how our test setup looks like as there seem to be some more
> people getting interested in it.

It would be great if you would send me the link when the article is ready.

> And I also want to point out, that establishing such vpn inter
> cloud links with the routers themselves has the following
> downside: With tinc + those DIR300 routers, we measured a maximum
> total throughput of 300kB/s which might be or might not be what
> you are looking for. This is because VPN software is copying the
> data from kernel to userspace and back a couple of times. Haven't
> measured anything with OpenVPN though, but as far as I know they
> are also doing this copying (there is no kernel module for OpenVPN
> afaik).
> 
> Cheers, Linus

Tanks, Floh1111

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]