I'm trying to use tinc to create a VPN between a single central location (with fixed IP address) and a number of "branch" locations with dynamic addresses. It's a star configuration. Each of the branches, and the server, has a /24 subnet of 10.119.0.0/16. The branches specify a single connection to the server, which is passive. Each of the host files specifies its /24 subnet, and the tun devices have the /16 netmask. The dynamic connections are either "nailed up" ppp or fixed broadband. (It's all one vpn, with a single tincd running on each host) Mostly, this works. Sometimes, however, vpn connectivity is lost between any two of the sites. Sometimes it's between a branch and the center (but the branch still has connectivity to other branches, via the center) or between branches (but each maintains connectivity to the center and other branches) However, the loss of connectivity is only one way; B2 cannot ping B1, but B1 can ping B2. Moreover, doing a ping from B1 to B2 will restore connectivity between B2 and B1. I'm running tinc 1.0pre8, on either 2.4.18 or 2.4.19. The problem most often occurs between a 2.4.18 branch with PPP and the 2.4.19 center. The center will be unable to ping the branch, but a ping from the branch to the center will restore everything. Other branches will have maintained full connectivity between the center and the affected branch throughout. The systems are running debian stable (woody) The problems don't appear to be related to PPP restarts. All the systems have iptables masquerading, but I assume it's not that because the loss of connectivity is partial. jim Tinc: Discussion list about the tinc VPN daemon Archive: http://mail.nl.linux.org/lists/ Tinc site: http://tinc.nl.linux.org/
On Fri, Sep 20, 2002 at 12:54:03PM +0100, Jim Chapman wrote:> However, the loss of connectivity is only one way; B2 cannot ping > B1, but B1 can ping B2. Moreover, doing a ping from B1 to B2 will > restore connectivity between B2 and B1.This sounds like there is a masquerading firewall or a firewall that only allows outgoing connections somewhere. These might drop UDP packets in one direction if there were no UDP packets going the other direction for more than a certain amount of time. You have three options: - Allow UDP packets to/from port 655 unconditionally in your firewall rules. - Send ping packets at regular intervals over the tunnel. - Add "TCPOnly = yes" to the host config files so that tinc won't use UDP to send packets. The first option is the best. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20020920/0e402111/attachment.pgp
On Fri, Sep 20, 2002 at 02:29:08PM +0100, Jim Chapman wrote:> I did think of that, however, I don't think that's the case > because this is a star configuration. A branch can lose connectivity > with the center, such that the center can't ping the branch but > if the branch pings the center things are happy again. However, > other branches still have full VPN connectivity to the 'dead' branch, > routed through the center (which is the center of the star) So UDP > is getting through in both directions between branch and center.If a branch wants to send something to another branch, the tinc daemon on the first branch will directly send it to the other branch. So packets between branches will never go via the center. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20020920/df75b149/attachment.pgp