On Sun, Sep 13, 2009 at 08:52:36PM +0200, Frithjof Hammer wrote:
> I have a good and well working tinc network connecting five subnets:
> 172.23.[42-46].0. Each is a /24 network. One of the nodes (172.23.43.1)
should
> provide a openvpn-dialin access on the net 10.10.10.0/24 to the 172.23.
> [42-46].0 network. I configured a static route on each tinc-node:
>
> route add 10.10.10.0/24 via 172.23.43.1
>
> Everthing looks fine, but it is not working: Pings are routed through the
> tinc-interface, but rejected there.
>
> Lets assume the following net topology:
>
> 172.23.42.1 ===(tinc-mesh)===172.23.43.1===(openvpn-dialin)===10.10.10.2
If you run tinc in router mode (the default), then "via 172.23.43.1"
does not
do anything. So it is equivalent to route add 10.10.10.0/24 dev $INTERFACE.
That is fine however, but you need to tell tinc where to route packets for
10.10.10.0/24 to. To do that, add "Subnet = 10.10.10.0/24" to the host
config
file of the node providing the openvpn-dialin access (172.23.43.1).
> If I ping 172.23.42.1 from a host, connected via openvpn as 10.10.10.2, the
> packtes flow from the host 10.10.10.2 to 172.23.43.1. The host 172.23.43.1
> will route the packets to the tinc interface (just wonderfull) and arrive
at
> 172.23.42.1. 172.23.42.1 will generate a echo-reply. But the echo-reply
will
> never make it back to 172.23.43.1:
>
> MarkTwain:~# tcpdump -i tinc -n
> tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to
> cooked socket
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tinc, link-type LINUX_SLL (Linux cooked), capture size 96
bytes
> 20:20:59.878230 IP 10.10.10.2 > 172.23.42.1: ICMP echo request, id
15626, seq
> 234, length 64
> 20:20:59.878370 IP 172.23.42.1 > 10.10.10.2: ICMP echo reply, id 15626,
seq
> 234, length 64
> 20:20:59.878453 IP 10.10.10.2 > 172.23.42.1: ICMP net 172.19.88.6
unreachable
> - unknown, length 92
The last packet is an ICMP Network Unknown packet, generated by the tinc daemon
running on 172.23.43.1.
> At this point, i wondering if this is a tinc related behavour, or if this
is a
> misconfiguration of my own. Can someone put me in the right direction?
> I suppose its tinc related, because the echo-replys never made it back to
> 172.23.43.1 or 10.10.10.2 (other then the tcpdump output indicates).
Adding the Subnet statement should solve the problem.
--
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/20090913/7e71dfb8/attachment.pgp>