similar to: Multiple default gateway from tinc node

Hi, Lars Thanks for your suggestion, will give it a try later to see how it performs. But, yesterday, I did a below test: A ConnectTo B and C, B ConnectTo D, C ConnectTo D; All nodes turned "IndirectData" on in its host configuration, so the tunnel only follow metacomnection instead of direct connect. D announced default route by having the Subnet = 0.0.0.0/0 statement in its host

Sure, let me reply all here for my finding. @Lars @Guus A’s tinc.conf: Name = bright AddressFamily = ipv4 ConnectTo = aly_hk A’s tinc-up: #!/bin/sh ifconfig $INTERFACE 10.0.0.110 netmask 255.255.255.0 A’s host config: Subnet = 10.0.0.110/32 (VPN address) Subnet = 192.168.31.0/24 (LAN address) IndirectData = yes (enabled for every tinc nodes) The node aly_hk (vpn address 10.0.0.3) connects with

Hi, Etienne In addition, is there any option or switch can turn of the automatic direct connection? For the example below, even A has the route to C and can establish UDP connection directly, but I need the traffic to go through B, how can I achieve that easily? (instead of remove something from A’s routing table, or manually block the connection between A and C) > On 1 May 2017, at 6:28 PM,

Hi, Etienne I took a look for the below host configuration parameter (IndirectData), the default is no. For the below example: A ConnectTo B, B ConnectTo C: If IndirectData = no (default), then A wouldn’t establish direct connection with C, but will be forwarded by B. If IndirectData = yes, then A will try to establish direct connection with C, even though A don’t have the statement of

Oh, thanks, in my current case, I haven’t config “Address” parameter in A’s host config, is this will make A prohibited it listen on the tinc ports? Question: 1. if I config “Address” in A’s config, and even though A is in a private subnet, it might still possible for A to establish connection with X(X is public IP address)? 2. If there any parameter to disable the direct connection discovery,

H, Narcissus Quick one for the below case, if node A have a direct connection to node B, and node B have a connection to node X, then I found node A will be able to talk to node X, but the communication path is go through node B, instead of build direct connection between A and X, is that right? I tested this in my environment. A >> B >> X > On 1 May 2017, at 3:07 PM, Narcissus

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

Hi, Guus I don’t quite understand what you describe below, to me, no matter tinc or any other router/PC get an IP packet, it will go to check with its route table, to match the destination IP against the route table for the next hop, if I put "ip route add default via <C’s VPN IP address> dev $INTERFACE", I thought tinc will match the packet’s destination IP to the “default”, and

Hi, All Here is the case: A, B, C, D all configured with "IndirectData = yes”, so connection only happens when there’s a “ConnectTo” in tinc.conf. Arrow indicate the “ConnectTo” direction Everything works fine earlier as below: 1. A connect to C, D connect to C 2. C is the transit node where only forward traffic between A and C 3. D advertise 0.0.0.0/0#2 4. A can access internet from D

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,

*You should repeat this for all nodes you ConnectTo, or which ConnectTo you. However, remember that you do not need to ConnectTo all nodes in the VPN; it is only necessary to create one or a few meta-connections, after the connections are made tinc will learn about all the other nodes in the VPN, and will automatically make other connections as necessary. * The above is from the docs. Assuming

Hi, Tinc Expert in my tinc.conf, the ConnectTo to host X is commented, like below: #ConnectTo = X and there is a script: /etc/tinc/netname/hosts/X-up, I thought commented the ConnectTo X wouldn’t trigger the X-up, but it did. Why? What’s the logic behind to trigger host-up? How can I avoid this except remove the host-up file? Bright Zhao

Hi, Tinc experts I’m on-boarding for Tinc for just quite a few days, and trying to setup the connection between one client to multiple server, where multiple vpn tunnels from the client to different server. From the documentation, it indicate the tinc.conf can support multiple ConnecTo, also the tinc can support multiple netname, like /etc/tinc/net1, /etc/tinc/net2. My question is, for my above

Hi, Guus I did some test regarding the points you mentioned below, and yes, you’re right, but some of points may need further adjusted: 1. The destination of IPv4 wouldn’t be changed, Yes I agree, that’s the goal and final destination for the communication. But during the path, it may be encapsulated into another packet(tunnel mode), where the outside IP header is the physical address, but the

Hi, Etienne Thanks for your clarification, and this helped a lot. And in order to get a better understanding for the mechanism of Tinc and the purpose of ConnectTo statement, can I think the ConnectTo is the way to get the node into the Tinc VPN domain, instead of establish VPN connection between nodes. Once any node ConnectTo the Tinc VPN domain, it learns all other nodes, subnets, and

Hi all! I still have never managed to fully wrap my head around how UDP data tunnels can be established between nodes. Everytime I think I understand it, I see something that confuses me again Just now I am seeing the following: I have nodes A, B + C A has everybody's keys and host configuration files. B and C only have A's key, and host config with A's public IP address. B and

I don't know why, but for my case, I reduced the tinc topology from a complex one(which provide layered redundancy) to a very simpled one(one connection), and that connection drop disappeared. Later, let me draw the topology and share the config to you to see if there's any findings of the cause. Guus Sliepen <guus at tinc-vpn.org>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017

Hi list, I have a question regarding routing in Tinc 1.1. Please consider the following example of a small network: • 5 nodes: A, B, C, D, E • C and E are nodes with very small bandwidth Meta connection graph: A – B – C – D │ │ └─ E ───────┘ Node configuration: • StrictSubnets = yes • AutoConnect = yes • B has Forwarding = internal, all other nodes have Forwarding = off All nodes

Hi all, I am currently deploying tinc as an alternative to OpenVPN. My setup includes a lot of nodes and some of them are sitting together behind the same router on the same network segment. (E.g. connected to the same switch.) I noticed, that those nodes do never talk directly to each other via their private ip-addresses, but instead use the NATed address they got from the router.

Hi, All Two remote tinc nodes(A, B) advertised the same route to the Tinc domain, and the local tinc node(C) has two ConnectTo to point to those two remote nodes, and I found, and let’s assume connection from C to A is better than C to B (better latency from ping) : 1. when two remote nodes are up, the traffic always send through A 2. when A is down, traffic send through B 3. when A recovered,