Hi all, I use tinc since 2 years between my MPLS sites in router mode, works like a charm. Today i am trying to make an ethernet bridge beetween 2 sites for video conference needs, the raison is that 1 side is behind nat, and i dont have access on the gate, other side is on public range. Because off H323 that doesn't handle unconfigured NAT, i would like to give a public IP to the video device. Video (V1) <==> Node 1 (N1) <=GATE / NAT=> WWW <=GATE / PUB=> Node 2 (N2) V1 has fixed public IP in the range of N2, and the ip of GATE has default gateway. N1 has eth0 on the lan, br0 is a bridge of eth1 (where i want to plug the video device) and the tinc interface. N2 has is public IP on br0, which is a bridge of eth0 and the tinc interface. The Tinc configuration, very simple in my case, seams ok, logs shows both sides are well connected, 'brctl showmacs' looks good, showing mac address of remote sites ect ... Packet capture on both br0 interfaces show broadcast traffic crossing the VPN. When i try to ping GATE from V1, i can see arp request crossing the VPN (on both br0 interfaces), packet capture on GATE show the arp reply, but this arp reply never come back on the bridge br0 of N2. (N2 is using GATE has default gateway too) I am not sure the problem is tinc related but i failed to found why it doesnt work, this is making me crazy. Any ideas would be appreciated. Regards, -- C?dric
On Wed, Mar 21, 2012 at 08:48:21PM +0100, C?dric Lemarchand wrote:> Today i am trying to make an ethernet bridge beetween 2 sites for video > conference needs, the raison is that 1 side is behind nat, and i dont > have access on the gate, other side is on public range. Because off H323 > that doesn't handle unconfigured NAT, i would like to give a public IP > to the video device.Sounds reasonable.> Video (V1) <==> Node 1 (N1) <=GATE / NAT=> WWW <=GATE / PUB=> Node 2 (N2) > > V1 has fixed public IP in the range of N2, and the ip of GATE has > default gateway.Hm, but if you want any host on the internet to be able to reach V1, the default gateway for V1 should be N2, not GATE.> N1 has eth0 on the lan, br0 is a bridge of eth1 (where i want to plug > the video device) and the tinc interface. > N2 has is public IP on br0, which is a bridge of eth0 and the tinc > interface.[...]> When i try to ping GATE from V1, i can see arp request crossing the VPN > (on both br0 interfaces), packet capture on GATE show the arp reply, but > this arp reply never come back on the bridge br0 of N2. (N2 is using > GATE has default gateway too)I think that is normal. The ARP request is a broadcast packet, so you should see that on all the interfaces. But the ARP reply is a unicast packet, so it is only sent to V1. The bridge on N1 should therefore not forward it to the VPN interface, so N2 will never see this ARP reply. But you seem to be implying that you cannot ping GATE from V1. It would help if you could show is the routing tables on V1, N1 and N2, and which IP addresses V1 and GATE have. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120322/c21e4c19/attachment.pgp>
On Thu, Mar 22, 2012 at 12:29:44PM +0100, Guus Sliepen wrote:> > Video (V1) <==> Node 1 (N1) <=GATE / NAT=> WWW <=GATE / PUB=> Node 2 (N2) > > > > V1 has fixed public IP in the range of N2, and the ip of GATE has > > default gateway. > > Hm, but if you want any host on the internet to be able to reach V1, the > default gateway for V1 should be N2, not GATE.Oh, I am maybe a bit confused. Which GATE are you talking about here? You have two in your diagram. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120322/9784547a/attachment.pgp>
Julian Bäume
2012-Mar-23 11:44 UTC
Tinc 1.0.17, switch mode and IPv6: set DecrementTTL = no
moin! Am Donnerstag, 22. M?rz 2012, 17:14:55 schrieb Guus Sliepen:> I just tried to reproduce this and it appears the DecrementTTL option > introduced in tinc 1.0.17, which defaults to "yes", causes neighbor > discovery to fail. This might be the cause of your problems. So try to add > this to your tinc.conf files: > > DecrementTTL = no > > And let me know of that solves the problem.Lately, I experienced problems in my setup, too. I?ve got a very simple network with one central server and one, sometimes two clients connecting to it. I didn?t have the time to investigate, but after reading this, I tried to set this option to "no". Now everything works fine, again. Is this considered a bug? Is there a work-around or something I can provide in the package of tinc, so other users might not run into this issue, when upgrading? I can?t think of a way to force this option into user?s config files, when they do an upgrade. Neither do I have a clue, how to communicate this. bye then julian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120323/b9eaf975/attachment.pgp>
Guus Sliepen
2012-Mar-23 12:48 UTC
Tinc 1.0.17, switch mode and IPv6: set DecrementTTL = no
On Fri, Mar 23, 2012 at 12:44:14PM +0100, Julian B?ume wrote:> Am Donnerstag, 22. M?rz 2012, 17:14:55 schrieb Guus Sliepen: > > I just tried to reproduce this and it appears the DecrementTTL option > > introduced in tinc 1.0.17, which defaults to "yes", causes neighbor > > discovery to fail. This might be the cause of your problems. So try to add > > this to your tinc.conf files: > > > > DecrementTTL = no > > > > And let me know of that solves the problem. > > Lately, I experienced problems in my setup, too. I?ve got a very simple > network with one central server and one, sometimes two clients connecting to > it. I didn?t have the time to investigate, but after reading this, I tried to > set this option to "no". Now everything works fine, again.Great.> Is this considered a bug?Yes.> Is there a work-around or something I can provide in > the package of tinc, so other users might not run into this issue, when > upgrading? I can?t think of a way to force this option into user?s config > files, when they do an upgrade. Neither do I have a clue, how to communicate > this.The work-around for users is to set DecrementTTL = no. To fix this in tinc itself, apply this patch: http://tinc-vpn.org/git/browse?p=tinc;a=commitdiff;h=b5e3bf1a85462f0c41638c11305d28f87af24395 But I will try to release a new version as soon as possible. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120323/cbc5b17b/attachment.pgp>
Julian Bäume
2012-Mar-23 17:07 UTC
Tinc 1.0.17, switch mode and IPv6: set DecrementTTL = no
Hi :) Am Freitag, 23. M?rz 2012, 13:48:28 schrieb Guus Sliepen:> The work-around for users is to set DecrementTTL = no. To fix this in tinc > itself, apply this patch: > > http://tinc-vpn.org/git/browse?p=tinc;a=commitdiff;h=b5e3bf1a85462f0c41638c1 > 1305d28f87af24395Cool :) I added this patch to the openSUSE-Version in my repository. Works fine again, even without setting DecrementTTL = no in tinc.conf. Thanks for providing a patch this quickly. bye then julian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120323/b4f0d506/attachment.pgp>