tinc - Oct 2017 - UDP connections on tinc

Hello,

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.

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?

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?

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?


Any suggestion will be appreciated.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20171010/e288d71d/attachment.html>

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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20171011/35a3a3cc/attachment.sig>