On Fri, Sep 25, 2015 at 04:51:22PM +0200, Marcus Schopen wrote: > > Maybe the timeout for UDP NAT mappings is a bit short on your Cisco. Try > > adding PingInterval = 30 to the tinc.conf on those clients, perhaps that > > will help. > > Thanks for pushing me into the right direction. I disabled "TCPOnly = > yes" on the host and started with "PingInterval = 30" on each client > behind the NAT. The tunnels from the host side were still unstable until > I reduced PingIntervall down to 10 seconds, which seems to work fine for > the moment.
Ok, that means by default the UDP NAT timeout on the Cisco is extremely
short.
> I check the manual of the the Cisco NAT for any TCP/UDP
> timeout settings, but there is no way to modify anything like "keeps
> TCP/UDP connections alive".
It wouldn't be called something like that, rather a "nat translation
timeout" or something similar.
> So should I keep this UDP configuration or would you go back to
> TCPOnly?
I'd keep the UDP setting. It does generate more background traffic
though, if you have to pay for bandwidth you could consider going back
to TCPonly.
> And another thing which came up since the clients (all in the same
> subnet) are running behind the NAT: the traffic in-between the clients
> run through the hosts and not locally/directly anymore, which means
> higher latency and outgoing traffic. I don't see any blocked packages on
> the client's firewall. Is there a way to let them talk directly again?
This is probably because the Cisco doesn't support hairpin routing. Add
LocalDiscovery = yes to tinc.conf on the clients, that way they can
detect each other's LAN address and do direct traffic again.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
