similar to: Tinc still run on single core of CPU?

Hi, My CentOS has upgrade the openssl to 1.1.1a, and I thought my tinc(1.0.35) installed by yum will use the new openssl, but it looks not the fact. So is tinc(1.0.35) support openssl 1.1.1a? If so, how can I make it running in this version of openssl?

Hi, All Due to some routing rotation purpose, I use crontab to add below info: 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 1 * * * * /usr/sbin/tincd -n myvpn -k 1 * * * * /usr/sbin/tincd -n myvpn --debug=3 30 * * * * sed -i '/54.169.128.0\/17/d' /etc/tinc/myvpn/hosts/aws_sgp

Saverio My current tinc 1.0.35 is running fine on CentOS, and recently and I upgrade the OpenSSL of the OS to 1.1.1a. After the upgrade, tinc works fine, but since the OpenSSL library is on a separate folder compared with previous version, I doubt tinc doesn’t use the new OpenSSL. Also, I doubted about whether tinc 1.0.35 support OpenSSL 1.1.1a as well, should I use the lastest tinc 1.1pre7 to

Let’s say, tinc A node server LAN-1(single internet circuit), tinc B node and tinc C node are both serve LAN-2.(two internet circuits) Normally, we can only set tinc A to connect to either B or C, and then the other set as backup. But in some circumstances, we would like to combine the internet pipe of both two circuits, so that the tunnel traffic can have a better bandwidth. If that’s the

I agree with the in-effective of TCP transmission, but I wonder if the the UDP packet is dropped, the tinc VPN itself wouldn’t retransmit, and if the upper level application doesn’t handle the packet loss well, will this be the problem? Or the upper level application have very limited tolerance to packet loss(like RDP application, I guess if the packet loss go to certain threshold, the connection

Hello, why it does not look like that ? Could you please explain what you mean ? thank you Saverio Il giorno lun 18 feb 2019 alle ore 15:02 Bright Zhao <startryst at gmail.com> ha scritto: > > Hi, > > My CentOS has upgrade the openssl to 1.1.1a, and I thought my tinc(1.0.35) installed by yum will use the new openssl, but it looks not the fact. So is tinc(1.0.35) support

Hi, Guus Thanks a lot for your suggestion, actually I did something else as below. But one question here is if I don’t add "/sbin/ifconfig myvpn 10.0.0.1 netmask 255.255.255.0”, it seems the crontab wouldn’t trigger tinc-up, and then the ip addr of myvpn wouldn’t be configured, then it will prompt the error of "Can't write to Linux tun/tap device (tun mode) /dev/net/tun:

We knew the TCP-BBR developed by google and try to optimize the transport efficiency of TCP, I’m wondering will this be beneficial if we put tinc in TCP mode plus the TCP-BBR?

> On 18 Jun 2017, at 15:44 , Bright Zhao <startryst at gmail.com> wrote: > > I agree with the in-effective of TCP transmission, but I wonder if the the UDP packet is dropped, the tinc VPN itself wouldn’t retransmit, and if the upper level application doesn’t handle the packet loss well, will this be the problem? > > Or the upper level application have very limited tolerance

If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP?

I have looked into this and it would definitely be possible, NETunnelProvider. It was not looking like a simple port though, a lot of glue required to get it to a state Apple would approve. This had been on my list of projects to attempt if I could find the time and energy to commit to it. If you do port it I would be very interested! Regards, Ryan Mounce On 26 July 2017 at 20:54, Bright Zhao

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, 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

Hi, Tinc expert If there’re multiple tinc nodes announce default route in their host configuration of Subnet = 0.0.0.0/0, how for the remaining nodes to select which is the best route to get out? All of them participant in the same tinc net. I did some test, like A as the branch, B,C,D as the nodes to announce default route; when all up , A select B, but if B down, A will go C, C down, A will

I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is natively designed to optimize TCP, instead of TCP-over-TCP, but could you articulate a bit more about the beneficial of “sending host when there is a UDP tinc tunnel” in the middle”? > On 30 Sep 2017, at 11:23 AM, Ryan Mounce <ryan at mounce.com.au> wrote: > > I'm not aware that BBR claims nor

Hi, You mean use the vpn link as active active? What service run for the vpn? If pure tcp load balance, iptables can do these needs. If http service you can use L7 load balancer On 29 Oct 2017 7:04 pm, "Bright Zhao" <startryst at gmail.com> wrote: > Let’s say, tinc A node server LAN-1(single internet circuit), tinc B node > and tinc C node are both serve LAN-2.(two

1. Is there any tools/command, we can show the subnet where a certain tinc nodes learnt? So that I can know the weight for certain subnet(in real time), instead of go back to the node’s (who advertise the subnet) configuration file to check. 2. So far in order to change the weight of a subnet, or something else, I have to reset the tinc daemon( tincd -k -n myvpn and then tincd -n myvpn) in

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

On Fri, May 26, 2017 at 09:30:44AM +0800, Bright Zhao wrote: > Due to some routing rotation purpose, I use crontab to add below info: > > 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 1 * * * * /usr/sbin/tincd -n myvpn -k > 1 * * * * /usr/sbin/tincd -n myvpn

Hello Guus. I've reading mailing list archives threads about it at http://www.tinc-vpn.org/pipermail/tinc/2011-July/thread.html#2757 and http://rutschle.net/pipermail/sslh/2011-July/thread.html and now trying to hide tinc server behind sslh multiplexer but without luck. First of all directly it works fine. Initiator (instance of tincd with ConnectTo statement) successfully establishes