tinc - May 2017 - How to set Subnet in a node which act as both server and client role?

Hi, Tinc experts

Diagram as below, A is trying to access host X behind C:

A >> B >> C — “host X"

B is the tinc server for A, but also B is the tinc client to connect to C.

My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
configuration for B will be tricky.

As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B) needs have
the Subnet = X/32, which indicate the VPN serve for this host.
But as the tinc client to C, B’s host config shouldn’t include Subnet = X/32,
because X/32 is behind C.

If not direct connection available from A to C, the only way I can figure it out
is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:

A >> vpn1 >> B >> vpn2 >> C — “host X”

If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
/etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side for
C.

Let me know if there’s any other simple way to achieve this.

There is no concept of "client" or "server" in tinc. tinc is
purely
peer-to-peer. "ConnectTo" statements only indicate which node will
attempt
to establish the initial connection, but once the connection is
established, direction does not matter.

It is unclear from your message which node is responsible for which subnet.
If X/32 truly belongs to C, then simply set Subnet = X/32 in C's local host
file. If you do that, then C will advertise this subnet to the rest of the
network, including B and A. There is no need to change anything in B's
configuration. tinc will take care of the routing for you, and A will be
informed (through the tinc protocol) that the subnet belongs to C, and that
any packets meant for X should therefore be sent to C.

These packets will then be sent directly to C using UDP (tinc is clever and
will try various NAT traversal techniques). If that's not possible for any
reason, tinc will automatically fall back to relaying packets through B.

On 1 May 2017 at 11:00, Bright Zhao <startryst at gmail.com> wrote:
> Hi, Tinc experts
>
> Diagram as below, A is trying to access host X behind C:
>
> A >> B >> C — “host X"
>
> B is the tinc server for A, but also B is the tinc client to connect to C.
>
> My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
> configuration for B will be tricky.
>
> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B) needs
> have the Subnet = X/32, which indicate the VPN serve for this host.
> But as the tinc client to C, B’s host config shouldn’t include Subnet >
X/32, because X/32 is behind C.
>
> If not direct connection available from A to C, the only way I can figure
> it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
>
> A >> vpn1 >> B >> vpn2 >> C — “host X”
>
> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
> /etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side
> for C.
>
> Let me know if there’s any other simple way to achieve this.
> _______________________________________________
> 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/20170501/283571dc/attachment.html>

Hi, Etienne

Exactly, I just did the test, remove the Subnet = X/32 from B, so I understood
that the Subnet on host configuration is indicate local attached network, or
let’s call it when going outside of the VPN domain.

And yes, A will try to establish UDP connection direct to C (if it has the
route), so the first time, I can ping from A to X, and I found the traffic
didn’t go through B, but second time, I remove the C route from A’s routing
table, then the traffic sent to B, and B sent to C; which exactly the same as
you indicate below.

Thank you very much, this makes me much better understanding on Tinc.
> On 1 May 2017, at 6:23 PM, Etienne Dechamps <etienne at edechamps.fr>
wrote:
> 
> There is no concept of "client" or "server" in tinc.
tinc is purely peer-to-peer. "ConnectTo" statements only indicate
which node will attempt to establish the initial connection, but once the
connection is established, direction does not matter.
> 
> It is unclear from your message which node is responsible for which subnet.
If X/32 truly belongs to C, then simply set Subnet = X/32 in C's local host
file. If you do that, then C will advertise this subnet to the rest of the
network, including B and A. There is no need to change anything in B's
configuration. tinc will take care of the routing for you, and A will be
informed (through the tinc protocol) that the subnet belongs to C, and that any
packets meant for X should therefore be sent to C.
> 
> These packets will then be sent directly to C using UDP (tinc is clever and
will try various NAT traversal techniques). If that's not possible for any
reason, tinc will automatically fall back to relaying packets through B.
> 
> On 1 May 2017 at 11:00, Bright Zhao <startryst at gmail.com
<mailto:startryst at gmail.com>> wrote:
> Hi, Tinc experts
> 
> Diagram as below, A is trying to access host X behind C:
> 
> A >> B >> C — “host X"
> 
> B is the tinc server for A, but also B is the tinc client to connect to C.
> 
> My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
configuration for B will be tricky.
> 
> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B) needs
have the Subnet = X/32, which indicate the VPN serve for this host.
> But as the tinc client to C, B’s host config shouldn’t include Subnet =
X/32, because X/32 is behind C.
> 
> If not direct connection available from A to C, the only way I can figure
it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
> 
> A >> vpn1 >> B >> vpn2 >> C — “host X”
> 
> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
/etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side for
C.
> 
> Let me know if there’s any other simple way to achieve this.
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
<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/20170501/76060377/attachment.html>

I cannot understand why you say the configuration for B will be tricky.

If you select the switch mode, and some machine can initiate a
connection to some other machine, until

there is a path, the whole net will behave as all the tap device were
connected to a single switch.

Is not a vpn in the strict ipsec meaning, you should see it more like an
encrypted VLAN.



On 05/01/2017 12:00 PM, Bright Zhao wrote:
> Hi, Tinc experts
>
> Diagram as below, A is trying to access host X behind C:
>
> A >> B >> C — “host X"
>
> B is the tinc server for A, but also B is the tinc client to connect to C.
>
> My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
configuration for B will be tricky.
>
> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B) needs
have the Subnet = X/32, which indicate the VPN serve for this host.
> But as the tinc client to C, B’s host config shouldn’t include Subnet =
X/32, because X/32 is behind C.
>
> If not direct connection available from A to C, the only way I can figure
it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
>
> A >> vpn1 >> B >> vpn2 >> C — “host X”
>
> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
/etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side for
C.
>
> Let me know if there’s any other simple way to achieve this.
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170501/50d5e5e5/attachment.sig>

You’re talking about Layer 2  bridging by Tinc? The use case here is layer 3
routing, but anyway, thanks for your feedback.

> On 1 May 2017, at 8:09 PM, LowEel <loweel at gmx.de> wrote:
> 
> I cannot understand why you say the configuration for B will be tricky.
> 
> If you select the switch mode, and some machine can initiate a
> connection to some other machine, until
> 
> there is a path, the whole net will behave as all the tap device were
> connected to a single switch.
> 
> Is not a vpn in the strict ipsec meaning, you should see it more like an
> encrypted VLAN.
> 
> 
> 
> On 05/01/2017 12:00 PM, Bright Zhao wrote:
>> Hi, Tinc experts
>> 
>> Diagram as below, A is trying to access host X behind C:
>> 
>> A >> B >> C — “host X"
>> 
>> B is the tinc server for A, but also B is the tinc client to connect to
C.
>> 
>> My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
configuration for B will be tricky.
>> 
>> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B)
needs have the Subnet = X/32, which indicate the VPN serve for this host.
>> But as the tinc client to C, B’s host config shouldn’t include Subnet =
X/32, because X/32 is behind C.
>> 
>> If not direct connection available from A to C, the only way I can
figure it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
>> 
>> A >> vpn1 >> B >> vpn2 >> C — “host X”
>> 
>> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
/etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side for
C.
>> 
>> Let me know if there’s any other simple way to achieve this.
>> _______________________________________________
>> tinc mailing list
>> tinc at tinc-vpn.org
>> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
> 
> 
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc