tinc Digest, Vol 123, Issue 13

Sun Jan 25 14:58:06 CET 2015

Lastest Modifications:

HOST A:
Removed 2 route add as you suggested, and it's still working.

HOST B:
This host has a openwrt as gateway and I added few days ago as you
suggested on freenode and this is HOST B Gateway route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    10     0        0 eth2
192.168.1.0     0.0.0.0         255.255.255.0   U     10     0        0 eth2
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0
br-lan
192.168.10.1    192.168.2.10    255.255.255.255 UGH   0      0        0
br-lan

HOST C:
Because of me thinking that those bridges on the gateway are messing
something with my IP ranges I changed range to be 192.168.5.0/24
so now host C has ip 192.168.5.10, this host uses openwrt ad gateway too,
so I set up a static route as in HOST B and it looks like

Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0
wlan0
192.168.0.0     *               255.255.255.0   U     0      0        0
wlan0
192.168.5.0     *               255.255.255.0   U     0      0        0
br-lan
192.168.10.1    192.168.5.10 255.255.255.255 UGH   0      0        0 br-lan

>From HOST A I can still ping HOST B's entire subnet
>From HOST A I can ping only 192.168.5.1 and 192.168.5.10 and here i'm lost
about the WHY!

Same situation goes from host C adding a static route doesn't even allow
clients to ping 192.168.10.1 or anything else.

It's not possible for me to install tinc directly on gateways because of
the lack of memory, so the static route seems the best solution, but as you
see isnt working, is there something else I could attach in order to give
you a complete situation?

Thanks in advance

Marco

2015-01-25 12:00 GMT+01:00 <tinc-request a tinc-vpn.org>:

> Send tinc mailing list submissions to
>         tinc a tinc-vpn.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
> or, via email, send a message with subject or body 'help' to
>         tinc-request a tinc-vpn.org
>
> You can reach the person managing the list at
>         tinc-owner a tinc-vpn.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tinc digest..."
>
> Today's Topics:
>
>    1. Re: tinc Digest, Vol 123, Issue 11 (Guus Sliepen)
>
>
> ---------- Messaggio inoltrato ----------
> From: Guus Sliepen <guus a tinc-vpn.org>
> To: tinc a tinc-vpn.org
> Cc:
> Date: Sat, 24 Jan 2015 16:51:44 +0100
> Subject: Re: tinc Digest, Vol 123, Issue 11
> On Sat, Jan 24, 2015 at 04:11:24PM +0100, Marco Avoledo wrote:
>
> > I think the /16 solution is the easier to apply so I modified my tinc-up
> in
> > host A to be like
> >
> > #!/bin/sh
> > ifconfig $INTERFACE 192.168.10.1 netmask 255.255.0.0
>
> Ok.
>
> > So at the moment their tinc-up are set up like this:
> >
> > HOST A:
> > #!/bin/sh
> > ifconfig $INTERFACE 192.168.10.1 netmask 255.255.0.0
> > route add -net 192.168.1.0/24 dev $INTERFACE
> > route add -net 192.168.2.0/24 dev $INTERFACE
>
> You don't need those route add -net ... statements anymore, since the
> ifconfig with netmask 255.255.0.0 will already have added a route to the
> kernel's routing table that covers those /24 subnets.
>
> > The situation is:
> > From HOST A I can ping every IP of HOST B subnet
> > From HOST A I can ping only few IP on HOST C subnet 192.168.1.1 and 1.101
> > is Okay, but 1.200 is not.
> > From HOST B I can ping HOST A and HOST B
> > From HOST C I can ping only few IP on HOST B subnet 192.168.2.1, 2.8 and
> > 2.10 are Okay but 2.2, 2.3 and 2.4 are not.
>
> I suspect packets from host A and B will be sent to other hosts one C's
> LAN just fine, it's the return packets that are the problem. You have to
> ensure that hosts on C's LAN know that they should send packets for host
> A or B to host C. There are several ways to do this:
>
> 1) Add routes to every node on C's LAN to send packets for the VPN
> address range to C.
>
> 2) Add a route on the gateway of C's LAN to redirect packets for the VPN
> address range to C.
>
> 3) Run tinc on C's gateway instead.
>
> 4) Set up NAT on host C such that packets from the VPN to its LAN are
> masqueraded.
>
> Options 1 and 2 require you to change settings on other hosts on C's
> LAN. Option 3 is the nicest option, but this assumes you can actually
> install tinc on the gateway device. Option 4 only requires changes on
> host C, but the drawback is that this only allows VPN hosts to initiate
> connections to hosts on C's LAN, not the other way around.
>
> I assume there is a similar problem on host B. But it's also strange
> that you can in fact reach 192.168.1.1, 192.168.2.1 and 192.168.2.8...
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus a tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc a tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- parte successiva --------------
Un allegato HTML � stato rimosso...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20150125/9fe4aa93/attachment.html>