Dear all, I have 3 nodes: A, B and C. C has external IP and A and B are behind NAT. It turns out A and B route their traffic via the C, which they ConnectTo with; this instead of getting connection details from one another and contacting eachother directly (mesh style). The reason is, as I conclude from tincd debug output, is that they see the peer as having a minimum MTU of 0. I suspect this is because both nodes happen to be behind the same NAT and thus have the same public IP, in this particular case. If I place the nodes in different NATed enviroments (different public IP's) it does work. Can this be fixed in a way such that nodes A and B do directly communicate? Thanks in advance, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20141205/26242f85/attachment.html>
Hi,> > Can this be fixed in a way such that nodes A and B do directly > communicate?In the experimental protocol of Tinc 1.1, there is LocalDiscovery which does exactly that. Cheers, Nik
Hi Eric, Which version are you using? I have similar issues with the newest 1.1pre10. Did you check out the ?LocalDiscovery? option? For 1.1, you also can get more information about the actual connection mode by using the ?info [node]? command. Cheers, Steffen> Am 05.12.2014 um 12:26 schrieb Eric Feliksik <feliksik at gmail.com>: > > Dear all, > > I have 3 nodes: A, B and C. C has external IP and A and B are behind NAT. > > It turns out A and B route their traffic via the C, which they ConnectTo with; this instead of getting connection details from one another and contacting eachother directly (mesh style). The reason is, as I conclude from tincd debug output, is that they see the peer as having a minimum MTU of 0. I suspect this is because both nodes happen to be behind the same NAT and thus have the same public IP, in this particular case. > > If I place the nodes in different NATed enviroments (different public IP's) it does work. > > Can this be fixed in a way such that nodes A and B do directly communicate? > > Thanks in advance, > Eric > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Hi Steffen, I'm using version 1.0.23, as I need a proven solution (stable) for these purposes. I did not know the LocalDiscovery option, thanks! It will not always work (sometimes there's multiple NAT with docker), but I can worry about that later. Cheers! Eric On Fri, Dec 5, 2014 at 1:37 PM, Steffen Vogel <post at steffenvogel.de> wrote:> Hi Eric, > > Which version are you using? I have similar issues with the newest > 1.1pre10. > > Did you check out the ?LocalDiscovery? option? > For 1.1, you also can get more information about the actual connection > mode by using the ?info [node]? command. > > Cheers, > > Steffen > > > Am 05.12.2014 um 12:26 schrieb Eric Feliksik <feliksik at gmail.com>: > > > > Dear all, > > > > I have 3 nodes: A, B and C. C has external IP and A and B are behind NAT. > > > > It turns out A and B route their traffic via the C, which they ConnectTo > with; this instead of getting connection details from one another and > contacting eachother directly (mesh style). The reason is, as I conclude > from tincd debug output, is that they see the peer as having a minimum MTU > of 0. I suspect this is because both nodes happen to be behind the same NAT > and thus have the same public IP, in this particular case. > > > > If I place the nodes in different NATed enviroments (different public > IP's) it does work. > > > > Can this be fixed in a way such that nodes A and B do directly > communicate? > > > > Thanks in advance, > > Eric > > > > _______________________________________________ > > tinc mailing list > > tinc at tinc-vpn.org > > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20141205/404c0143/attachment.html>