Configuration Help. Ping says Destination unreachable.

[Guus Sliepen]

On Sun, Jun 08, 2003 at 10:16:18AM -0700, Jason wrote:

> > Use Subnet = 192.168.0.0/24 for mia and Subnet = 192.168.2.0/24 for
> > zidler. Since the whole VPN is larger than a /24, you should use
> > something like this in tinc-up on both sides:
> > 
> > ifconfig $INTERFACE 192.168.0.0 netmask 255.255.0.0
> 
> Just a side note..  this doesn't always work for everyone.  What if the 
> subnets were far enough apart that the smallest netmask that 
> encompasses both of them is overly broad and included other unrelated 
> subnets?  For example, in my personal vpn, one machine hosts a 192.168.x.x 
> subnet and the other machines host 10.10.x.x subnets.  With the above 
> technique, I'd have to give the vpn interface an ip of 0.0.0.0/0 to cover 
> all private subnets.  This would obviously not work because it would 
> encompass the entire IP range.  It is using a broad netmask on the 
> interface in lieu of just setting up the routing table correctly.

In that case, something like this would be a solution:

ifconfig $INTERFACE 192.168.0.1 netmask 255.255.0.0
route add -net 10.10.0.0 netmask 255.255.0.0 dev $INTERFACE

[switch mode]
> physical switch does).  This generally worked well but over time I
> discovered why switch mode is still considered experimental... When it
> worked, it worked well.  But over time it would sometimes just all break
> (I think triggered by occasional Internet network connectivity issues) and
> to get it going agian I'd often have to stop tincd on ALL boxes in the vpn
> and then restart it on all to get things back in sync and working again.

Hm, you're probably experiencing the same problem as Marc Lehmann, you
could try the CVS version which should contain a fix.

[...]
> it was no longer doing dynamic MAC learning like a switch does.  But what
> I didn't expect is that now I have to also add all of the subnets of the
> remote networks into the host files with Subnet lines.  To me, this seems
> redundant, since I'm already telling the kernel which VPN IP to route
> those packets to, and tinc already knows which host to send each VPN IP 
> to.  But I guess with ARP disabled, the kernel just sends the packet out 
> the interface and tinc has no way of knowing which next-hop VPN IP the 
> kernel intended the packet to go to.  

That's right. The kernel has just one route for all packets to the VPN,
tinc has to know more than that.

> I was starting to ramble there so I hope that made sense.

Yes :)

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20030609/1cf19fe9/attachment.pgp