routing trouble

[Guus Sliepen]

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>