tinc Digest, Vol 156, Issue 4

[Heng Wang]

Thanks Guus. Appreciate the help.
What's the purpose of SUBNET msg? Is it even useful in switch mode?

I tweaked the code to disable SUBNET msg, because I thought they weren't
useful when it comes to switch mode.
Which caused the UDP connection got blocked apparently. If I re-enable
SUBNET msg, the udp connection starts
to work fine. I don't see any forwarding traffic any more.



On Thu, Oct 12, 2017 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote:

> Send tinc mailing list submissions to
>         tinc at tinc-vpn.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
> or, via email, send a message with subject or body 'help' to
>         tinc-request at tinc-vpn.org
>
> You can reach the person managing the list at
>         tinc-owner at tinc-vpn.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tinc digest..."
>
> Today's Topics:
>
>    1. Re: UDP connections on tinc (Guus Sliepen)
>
>
> ---------- Forwarded message ----------
> From: Guus Sliepen <guus at tinc-vpn.org>
> To: tinc at tinc-vpn.org
> Cc:
> Bcc:
> Date: Wed, 11 Oct 2017 19:20:06 +0200
> Subject: Re: UDP connections on tinc
> On Tue, Oct 10, 2017 at 10:48:22AM -0400, Heng Wang wrote:
>
> > We are using tinc 1.0.24 with switch mode. Some questions regarding to
> the
> > UDP connections on tinc.
> >
> > As far as I understand tinc is building meta connections with
> "ConnectTo",
> > and "ADD_EDGE" packet. With the help of EDGE info two nodes who don't
> have
> > direct meta connection are able to communicate through direct UDP
> > connection.
>
> Correct.
>
> > I understand we can dump the meta connection using USR2 signal. However
> is
> > there a way to know if a direct UDP connection exists between two nodes?
>
> If you do USR2 you also get a list of nodes. There's quite a lot of
> information for each node. Look at the min mtu value, if it is greater
> than 0, you have a direct UDP connection to that node. However, UDP
> connections are made on-demand, so if you haven't sent anything to that
> node yet, it will likely still be 0.
>
> > UDP connection will fall back to the meta connection(with next-hop..) if
> > the direct UDP fails, but what are the possible reasons for its failure?
>
> It could be a NAT device that doesn't allow UDP hole punching, or a
> firewall that blocks tinc's UDP packets. These problems might exist at
> either peer, or somewhere inbetween.
>
> > Currently we have a connection like below:
> >
> > A-->H
> > G-->H
> > D-->A
> > E-->A
> > F-->A
> > If we try to send packets directly from G to D, seems the direct UDP
> > connection always fails and it is going to path G-->H-->A-->D, however
> > somehow it got broadcasted during the process, because I can see that
> > message on E and F. Does this even make sense?
>
> Yes, if it gets broadcast in switch mode, that means that tinc didn't
> know which node had the destination address. Just like a real physical
> Ethernet switch, if you send packets to a MAC address that it doesn't
> know, it will broadcast it on all ports. So it could be that you are
> sending a packet to the wrong IP address, or that it's the right IP
> address but the node that should have that IP address is misconfigured
> somehow, or it could be that that node is offline.
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://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/20171012/bb52f3cc/attachment.html>