similar to: Reliability between TCPonly and UDP for tinc?

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

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,

Hello, response time: how is it possible to increase the response time on Tinc VPNs. When I use tinc over a fast or giga-bit network connection the ping-response time is normally about 1800 to 2000 ms. Sometimes I get ping response times at about 2.500 to 3.000 ms over a normal Ethernet Connection or a television-cable connection within the same providers-network in the same city. The ping-time

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,

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

Hi there! Today I've tried a FTP connection (me with TCPOnly send file to another no TCPOnly), but the upload bandwidth was about 20 kb/s, while connecting to the other directly (I upload a file to him via FTP) the connection was about 5 times faster... what's wrong? thanks

Hi there! Today I've tried a FTP connection (me with TCPOnly send file to another no TCPOnly), but the upload bandwidth was about 20 kb/s, while connecting to the other directly (I upload a file to him via FTP) the connection was about 5 times faster... what's wrong? thanks

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, I've successfully running tinc1.0pre4 between two locations on SuSE Linux 7.1 in a special masquerading Firewall environment, so that I'm using the TCPonly keyword in the host files to get a connection. Otherwise I would get the message 'Received UDP packet on port 655 from unknown source <ipaddress in hex:port>'. After upgrading to 1.0pre5 I'm getting this message

Hello, I am experiencing some weird problems in a setup with tinc where communication between the 'server' and the 'clients' occur over 3g connections. Let me describe briefly the setup: - The server, on a public IP, runs tinc 1.0.8, in router mode, and the whole setup uses one VPN network. All client's VPN addresses are on the same subnet, and each client has a seperate

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

Hi, I upgraded some of my Tinc nodes from 1.0.8 recently and found something strange. All of a sudden, the vpn would not work as a full-mesh. Certain nodes were not contactable. I re-generated my rsa-keys, and checked my configuration. My vpn uses the following in tinc.conf, as I am routing both ipv4 and v6. === name = node1 mode = switch AddressFamily = any PMTU = 1280 PMTUDiscovery = yes

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

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 there! I'm totally new to the concept 'self-made VPNs' :P I've discovered tinc and I think it's not as easy as hamachi, but not so hard as OpenVPN :D Now: I've got 4 questions: question n.1: I'm behind a router. This router is configurable, but I'm also behind a provider's NAT (private IPs with a common public IP). Will tinc work, or it will do as

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

Hey, Tinc developers! I'm not sure if anyone else has brought this up, but we've got a rather good reason for using TCP, even though UDP will actually form a working connection. Anyone on Comcast's "small business" service is forced to use an SMC cable modem/router. Its NAT implementation is capable of letting tinc's UDP tunnels work fine, but they limit a single UDP

Guus, [tinc version 1.0.24] Consider the case where you have the following setup client - fw - server The client and server successfully setup a tunnel and UDP communication starts to happen. Then the client shuts up and the server only needs to send data to the client if the remote tool accesses the client?s UI. If the firewall times out the NAT UDP hole, the server has a problem: The UDP