tinc and routing
Guus Sliepen
> Does tinc support gateway routing to other networks across its interfaces?
In router mode (the default), no. But on the other hand, you don't need
gateway routes when running tinc in router mode, and normally gateway
routes do work but the gateway address is ignored (either by the kernel
or by tinc).
If you explicitly want traffic from 172.16.1.0/24 to go to
192.168.0.0/24 via the tinc daemon on 192.168.9.1, you should add
"IndirectData = yes" to the host config file of the tinc daemon of
172.168.1.0/24, otherwise tinc will send traffic from 172.168.1.0/24's
tinc daemon directly to 192.168.0.0/24's daemon, without sending it
first to 192.168.9.1.
> The problem I am having is that on any host in 172.16.1.0/24 if I
> attempt to ping a host on 192.168.0.0/24 the packets get dropped somewhere.
> Traceroute shows.
You can get more information from tinc using the -d and -D options.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <gu...@sliepen.eu.org>
Clark Rawlins
The 192.168.9.1 machine is multi-homed with 172.16.1.1 so they
are the same machine.
I added
IndirectData = yes
and I still get the same results.
What I had hoped would happen is that traffic from 192.168.0.0/24
headed for 172.16.1.0/24 would be routed via the vnc device to the
gateway specified for 172.16.1.0/24 which is 192.168.9.1 from there
the traffic would be routed to the eth2 interface which is the local
subnet on the multi-homed host 192.168.9.1 - 172.16.1.1 and from there
to its final destination.
This doesn't seem to happen for some reason.
You said that the gateway router gets ignored by either the kernel or
by the tinc daemon? My understanding (which may be flawed) was that for
a gateway route the kernel receives a packet, examines it's destination,
and then compares it to the entries in the routing table. For each entry
in the routing table it bit wise ands the destination address with the
subnet mask for the routing entry and then if the result is equal to the
network in the routing entry it is sent to the interface and in the case of
gateway route to the host specified as the gateway.
Then in the case of ethernet the kernel would look up the hardware address
for
the gateway router in the arp table and if not found arp on the destination
interface for the gateway address.
Once it has the hardware address for the gateway address it sends the packet
to the gateway address as an ethernet unicast message.
I don't know how this compares to what tinc does perhaps
you could enlighten me?
Clark
--
TINC development list, tinc-...@nl.linux.org
Archive: http://mail.nl.linux.org/tinc-devel/
Guus Sliepen
> I'll try that but to clear up an apparent misunderstanding:
> The 192.168.9.1 machine is multi-homed with 172.16.1.1 so they
> are the same machine.
Ah okay, that explains why IndirectData doesn't have any effect :)
> What I had hoped would happen is that traffic from 192.168.0.0/24
> headed for 172.16.1.0/24 would be routed via the vnc device to the
> gateway specified for 172.16.1.0/24 which is 192.168.9.1 from there
> the traffic would be routed to the eth2 interface which is the local
> subnet on the multi-homed host 192.168.9.1 - 172.16.1.1 and from there
> to its final destination.
Hm. Could you send me your tinc-up scripts and the configuration files
in the hosts/ directory?
> This doesn't seem to happen for some reason.
> You said that the gateway router gets ignored by either the kernel or
> by the tinc daemon? My understanding (which may be flawed) was that for
[...]
> Once it has the hardware address for the gateway address it sends the packet
> to the gateway address as an ethernet unicast message.
Correct.
> I don't know how this compares to what tinc does perhaps
> you could enlighten me?
Why the kernel would ignore the gateway address:
If you use tinc 1.0 or later and the universal tun/tap device from the
Linux kernel, tinc will use that device in tun mode, which means it is
not an Ethernet interface, but a pure IP interface. In that case, there
are no Ethernet addresses involved, and the gateway address is not used
at all by the kernel.
Why tinc would "ignore" the gateway address:
Well in router mode, tinc can only route IPv4 and IPv6 packets. ARP is
not an IPv4 protocol, it is something Ethernet specific. It does not
forward broadcast ARP requests to all other tinc daemons in the VPN.
However, tinc has built-in proxy-arp that will fake replies for ARP requests it
receives on the virtual network device. If you specify a gateway address
for the route, then the kernel will send ARP requests for that gateway
address. If you omit it, then the kernel will send ARP requests for the
destination address of the packets you send. Tinc responds to both
requests, the kernel is happy because it now knows an Ethernet address,
sends it to the virtual network device, and tinc will route the packets
to the correct destination tincd (without looking at the Ethernet
address, just at the IP addresses in the packets).
Clark Rawlins
needs to handle packets for additional networks.
In the host file (on each machine in the vpn)
Adding an additional Subnet line
Subnet = 172.16.1.0/24
lets tinc know to route packets for that network to that host.
Clark
> -----Original Message-----
> From: Guus Sliepen [mailto:gu...@sliepen.eu.org]
> Sent: Friday, October 10, 2003 10:37 AM
> To: tinc-...@nl.linux.org
> Cc: Clark Rawlins
> Subject: Re: tinc and routing
>
>