Configuration Help. Ping says Destination unreachable.

[Jason]

On Sun, 8 Jun 2003, Guus Sliepen wrote:

> On Sun, Jun 08, 2003 at 07:53:39AM -0500, Shashank Khanvilkar wrote:
> 
> > OK.. I thought subnet meant the private subnet behind a firewall.
> > Actually I am using a setup like the below:
> 
> It does indeed mean the private subnet behind the firewall.
> 
> > http://mia.ece.uic.edu/~papers/volans/networksetup.jpg
> 
> You don't need to have a seperate subnet for the tunnel, just use the
> same address you have on the private subnet for the tunnel endpoints.
> So no need for 192.168.254.200 and 192.168.254.201, just use 192.168.0.1
> and 192.168.2.1.
> 
> 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.

What I wanted to do was basically have the VPN act the same as if all 
hosts on my VPN had an extra ethernet card plugged into them and those 
cards all hooked up to one new switch/hub.  Then I would assign that newly 
created subnet a new range of IPs (the "VPN subnet") and just setup the 
routing tables on all boxes appropriately so that each box used the normal 
Linux routing code to determine where a given subnet should be routed.  

When I read the tinc docs, the "switch" mode sounded perfect for me and
that's how I set it all up.  It was nice because I didn't have to have
Subnet lines in any of the host config files.  tinc-up on each box just
set the vpn interface up with its own ip in the VPN subnet (a new /24 just
for that purpose) and then setup route lines to reach all of the other
subents hooked to the other VPN participants.  I also gave each interface
its own unique MAC address (I used the convention fe:fd:0:0:0:n where n is
the last digit of the ip in the vpn subnet)  so that the kernel can use
ARP to determine which MAC has a given IP (just like real ethernet) and
the switch code could learn which host to send each MAC to (just like a
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.

I then switched to router mode and I haven't had those problems with the
VPN occasionally dying.  I still have my tinc-up setup the same way (with
a VPN subnet that each interface gets configured into, with additional
route lines then added to reach all of the other private subnets attached
to all of the vpn hosts, routing those subnets to the appropriate host's
VPN subnet IP), with the exception of the MAC addrs all being set to the
magic fe:fd:0:0:0:0 and arp being disabled.  And I knew that I would have
to then also add the VPN IP into each host's config file with a Subnet
line (as a /32) so that tincd would know which host to route it to since
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.  

Bottom line is that for how I want it (separate vpn subnet), switch mode 
is best but isn't stable yet..  But for those of you wanting to use router 
mode but don't have your private subnets all right near to each other in 
the global IP space, you have an alternative way to configure it that 
works.

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

Jason


Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/