tinc - Mar 2010 - Routing issue

Hi,

I just set up tinc between two hosts (for now). All seems to work fine,
but now I run in to a routing issue:

I gave both of my vpn routers an IP in the 172.16.100.0/24 range, and
used the Subnet-directive to inform tinc of this. This works fine, I can
ping both hosts from both sides of the vpn.

Ofcourse both vpn routers give access to other subnets, but they don't
know the IP-ranges (i.e. I didn't supply Subnet-directives for those),
that's also impossible because network topology changes so the other
subnets are dynamic.
Therefore I use ospf (quagga) to dynamically determine
routing-information. This works fine, and it has always worked fine with
other VPN implementations (OpenVPN and CloudVPN). Both routers see
eachothers ospf daemon and exchange routes, no problem. However the
problem is that these routes aren't actually working.

When I try to ping an IP on the other end of the VPN, I get the following:

# ping 192.168.4.1
PING 192.168.4.1 (192.168.4.1) 56(84) bytes of data.

On Fri, Mar 12, 2010 at 07:10:42PM +0100, Erik Logtenberg wrote:
> I gave both of my vpn routers an IP in the 172.16.100.0/24 range, and
> used the Subnet-directive to inform tinc of this. This works fine, I can
> ping both hosts from both sides of the vpn.
[...]
> When I try to ping an IP on the other end of the VPN, I get the following:
> 
> # ping 192.168.4.1
> PING 192.168.4.1 (192.168.4.1) 56(84) bytes of data.
> From 192.168.4.1 icmp_seq=1 Destination Net Unknown
> 
> Note that there is no lag. This error comes from the local end of the
> VPN tunnel. I checked everything, from route tables to firewall
> configuration. I can only assume that tinc gives these errors, probably
> because it doesn't know about these subnets.
Yes, tinc will generate ICMP packets for unknown or unreachable destinations.
Indeed, since you only supplied Subnets for the 172.16.100.0/24 range, it does
not know about 192.168.4.1 and therefore doesn't know how to route those
packets.
> I think this should just work. The route to 192.168.4.0/24 is configured
> with the other vpn router as gateway, so as far as tinc is concerned, it
> should just forward the traffic to that host (which by itself is
> reachable) and let the other side care about routing the traffic
> further. With ospf this is always configured correctly on both sides, so
> it should always work.
The problem is that in the default mode, tinc will act as a layer 3 router. A
gateway route only makes sense on layer 2 networks. If you send a packet to
192.168.4.1, there is no mention of 172.16.100.x at all in the IP packets, so
tinc does not know that you want those packets forwarded via a gateway.
> Is there any way to have tinc allow this traffic?
Yes, use Mode = switch to let tinc act as a layer 2 switch. Then your gateway
routes will work as you intended. You also do not need the Subnet statements
anymore.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20100314/8647e727/attachment.pgp>