search for: directonly

...nectTo can make a direct connection to you. This is especially useful if you are behind a firewall and it is impossible to make a connection from the outside to your tinc daemon. Otherwise, it is best to leave this option out or set it to no. Also in Main configuration there’s another parameter (DirectOnly), the default is no, to continue the above example: A ConnectTo B, B ConnectTo C: If DirectOnly = no(default), and IndirectData = no(default): A can only sent data to B, and B will forwarded to C. If DirectOnly = no(default), and IndirectData = yes: A will try to send data directly to C, but if A...

...i, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo = TincKnoten1 GraphDumpFile = /tmp/tinc-graph LocalDiscovery = yes ClampMSS = yes PMTU = 1400 #DirectOnly=yes #IndirectData=yes Cipher=AES-128-CBC #TCPOnly=yes mac:10.0.0.20 (1gig directly to our backbone via...

Dear all, I like tinc and am using it widely in the company I work for. Currently I'm experimenting with 'switch' mode & have a problem with packets being forwarded. I've tried possible combinations with next parameters: a) Broadcast = direct b) Forwarding = kernel c) DirectOnly = yes From the documentation, it looks like (a) should be enough to stop packet forwarding between tinc nodes. But non of those parameters or combinations of them have helped me. The target is: if we have Router_A---------Router_B----------Router_C, A and C don't have direct connection, the...

Hello, I am tying to create tinc vpn for the ~1000 nodes and was thinking why meta connections are needed at all if I only need static configuration where every node knows addresses of other hosts and due to the amount of traffic any indirect connections will not work, so DirectOnly=yes is a must and then passing around routing information is not needed, right? Currently I have 10 nodes that are targets to ConnectTo for all other nodes, and all they are doing is processing ADD_EDGE requests. So I was thinking: 1. is it possible to start mesh vpn with only hosts file and n...

...h traffic levels. The traffic is application server to database server connections and multicast communication for session-replication on the application server. I'm running the tinc daemons in switch mode, to support the multicast. I have tried settings: TunnelServer = no Forwarding = off DirectOnly = yes To see whether that has an effect on CPU usage; which I haven't confirmed yet. There aren't any special settings per host, just the address and the key. 1.0.11 is the latest package of Tinc I can find for Ubuntu 10.04; is it worth me trying to build or find a package for 1.0.16?...

...ing with the hosts that are still reachable and that it recovers itself and we do not have to stop and start the whole network manually. We already tried to tweak the configuration to limit the amount of metadata by only having 3 ConnectTo hosts (the same ones everywhere) and using Broadcast = no DirectOnly = yes Cipher=aes-128-cbc (Apart from Name, AddressFamily, BindToAddress, Interface and ConnectTo that are the only settings we use in tinc.conf). We are also going to increase PingTimeout to 30 and reduce the number of ConnectTo hosts to 2. Is there anything else we can do to limit the amount of...

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,

...sts are running latest tinc-1.0 stable. The server is configured as a bridge and is relaying multicasts continuously. Below is the server configuration. Name = tserver AddressFamily = ipv4 BindToAddress = 192.168.21.254 30000 KeyExpire = 28800 ReplayWindow = 0 DeviceStandby = no DeviceType = tap DirectOnly = yes Mode = hub ProcessPriority = high ClampMSS = yes Cipher = none Digest = none MACLength = 0 PMTUDiscovery = yes I have taken out what I believe is performance sapping options in an effort to boost performance. All clients (Windows 7) configuration is identical save its own name. Name = <...

*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

Ok so I'm up and riding with Icecast2 and ices2, thanks for all of you who pointed me in the right directon. I can stream fine without reencoding but when I change the nominal-bitrate tag its not happy. Comments in the xml file say: <!-- Live encoding/reencoding: Currrently, the parameters given here for encoding MUST match the input data for channels and sample rate. That restriction

.../pipermail/tinc/2015-December/004325.html , we see > the same messages in our logs as described there). [...] > We already tried to tweak the configuration to limit the amount of metadata > by only having 3 ConnectTo hosts (the same ones everywhere) and using > > Broadcast = no > DirectOnly = yes > Cipher=aes-128-cbc These options do not directly affect metadata. In particular, "DirectOnly = yes" may actually cause nodes to be less reachable than without that option. > We are also going to increase PingTimeout to 30 and reduce the number of > ConnectTo hosts to 2....

...we > see > > the same messages in our logs as described there). > [...] > > We already tried to tweak the configuration to limit the amount of > metadata > > by only having 3 ConnectTo hosts (the same ones everywhere) and using > > > > Broadcast = no > > DirectOnly = yes > > Cipher=aes-128-cbc > > These options do not directly affect metadata. In particular, > "DirectOnly = yes" may actually cause nodes to be less reachable than > without that option. > > > We are also going to increase PingTimeout to 30 and reduce the num...

On Mon, 4 May 2020 18:45:19 +0200 (CEST) Sven-Haegar Koch <haegar at sdinet.de> wrote: > On Mon, 4 May 2020, Pallinger Péter wrote: > > > ------- TL;DR ------- > > > > Performance seems slow (around 300-400Mbit peak). > > How to improve? > > Not sure if that could be the case for you, my links are not that > fast: > > Make sure to disable

...tions that's the problem? We're running 1.0.24 as it's the latest in the repos, but we did also test it with 1.0.30, but it made no difference. The common settings for every host in tinc.conf (just BindToAddress and Name are host specific): AddressFamily = ipv4 Forwarding = internal DirectOnly = no Device = /dev/net/tun MinTimeout = 2 MaxTimeout = 300 PingTimeout = 90 TunnelServer = yes Broadcast = no hosts configurations: Port = 655 Compression = 0 Cipher = aes-128-cbc IndirectData = no Thanks! Tuomas Silen -------------- next part -------------- An HTML attachment was scrubbed......

...rd ARP requests, and things are back to normal. The roaming node seems to initiate ARP resolution, while the central node does not. Any points as to why the central tinc is not doing / able to do the ARP request? tinc.conf on the central node: Device = /dev/tap1 Name = centralnode Mode = switch DirectOnly = yes TunnelServer = yes PingInterval = 60 PingTimeout = 15 ReplayWindow = 0 BindToAddress = 192.168.50.82 BindToAddress = 192.168.50.84 BindToAddress = 192.168.50.83 tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> ether 42:00:00:...

We run tinc in a linux environment in which it sits there waiting for connections from the clients. All clients are configured to only have one ConnectTo which points to this server. We're seeing in the server log that as soon as a client's connection is activated, a whole bunch of "Flushing x bytes to that host would block" is logged and the whole vpn is bogged down and has

...ve to call time() too often. | - MAC addresses expire after a time configurable by MACExpire (default 600 | seconds) `---- Is there a security motivation involved? Would it be possible to disable it completely? I am running babel routing protocol with tinc with options Forwarding=off, DirectOnly=yes and Broadcast=direct. In this configuration, tinc only takes care of the tunnel mesh, leaving forwarding completely to babeld and kernel. I find the connections getting interrupted whenever the MAC address of the tinc interface changes. I have to set MACExpire=31536000 to tinc.conf mitigate...

...y using the > configuration below. Sometimes. It varies between 350 and 500 Mb. > > Cipher = aes-128-cbc > Digest = none > # these did not really have any significant impact > #ClampMSS = no|yes > #Compression = 0 > Hi, I didn't study the internals but maybe changing DirectOnly, Forwarding and IndirectData will have an impact on per packet performance and speed stability by disabling some of the meshing features? Although it probably just hit the CPU limits again did you try Compression 0 vs 1 vs 10? Sorry that it's just speculation, these are just things I never go...

...related to servers and general infrastructure. Recently another potential use-case appeared: providing a VPN for remote devices (located at customer sites and maybe not exclusively under our control). The tinc configuration allows to restrict the direct traffic between such remote devices easily: DirectOnly = yes Forwarding = off TunnelServer = no The tricky part seems to be meta data: every node is aware of all other nodes (and partly also their IP addresses). This is not desirable in a context where devices from multiple customers would be part of the same network. Can you imagine a trivial solu...

With pleasure we announce the release of version 1.0.13. Here is a summary of the changes: * Allow building tinc without LZO and/or Zlib. * Clamp MSS of TCP packets in both directions. * Experimental StrictSubnets, Forwarding and DirectOnly options, giving more control over information and packets received from/sent to other nodes. * Ensure tinc never sends symbolic names for ports over the wire. This version of tinc is compatible with 1.0pre8, 1.0 and later, but not with earlier version of tinc. -- Met vriendelijke groet /...