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 at tinc-vpn.org>:
> Send tinc mailing list submissions to
> tinc at 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 at tinc-vpn.org
>
> You can reach the person managing the list at
> tinc-owner at 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 at tinc-vpn.org>
> To: tinc at 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 at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at 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>