similar to: What's the possible cause of UDP probe failure?

I found the server(1.1.1.1) didn’t receive the MTU probe from client, so I add iptables -A INPUT -p udp —port 443 -j ACCEPT. After this, I see one packet matching on the server side, and the MTU negotiation works, but when I tear down the tinc, and re-establish the tinc connection, the counter of below UDP/443 never increase, and also my other tinc nodes never add this statement on iptables, but

Hi, experts for example, the below case: You can see a lot of back and forth MTU probe packets been exchanged between tinc nodes, but it’s weird that, from the debug log, one line shows "No response to MTU probes from node1”, but it indeed received a lot of MTU probe response, and finally it get the conclusion of "Packet for node1 (1.1.1.1 port 443) larger than minimum MTU”.

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

> 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

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

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

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

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

I don't really think Address config in node description will decide it will listening for the public connection or not. From my own case, even if a real private node(pppoe dynamic address, tcp port listening not allowed, but Udp allowed) can have a p2p direct connection, I think it based on udp NAT traverse, but if you use TCPonly for this node, and also forbidden the incoming traffic to this

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

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

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?

Yes. Look up the "IndirectData" configuration option. On 1 May 2017 at 11:30, Bright Zhao <startryst at gmail.com> wrote: > 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,

Indeed it depends, tinc will have a port listening for incoming connections(both tcp and udp), if A have exposed its listening ports, a direct connection will be tried to build between the nodes, otherwise it will go from the intermediate node. -- Narcissus Emi 日時: 2017年5月1日 15:12:16, Bright Zhao (startryst at gmail.com) が書きました:: > H, Narcissus > > Quick one for the below case, if

Hi all I try to use tinc within my network, but I find almost all mtu probe take 30 times to fix, it's never really fix at all. after read code, i think the problem case by function receive_udppacket(); and line : origin -= MTU / 64 + 20; here , MTU / 64 + 20 =43, this means, every time we send a mtu probe packet, we get a reply smaller then what we send. review the commit log, the line

The only time I can think off, that you’ll *want* to use TCP, is when UDP doesn’t work through the firewalls/NATting. > On 18 Jun 2017, at 14:53 , Bright Zhao <startryst at gmail.com> wrote: > > 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? The problem with TCP, is that TCP,