search for: tunnelserver

Hello, Here is a patch for protocol_subnet.c with two modifications : - in tunnelserver mode, tinc must check subnets in the ".../hosts/owner" config file, not in "c->config_tree" (which is the configuration of the meta-connection from which we receive the ADD_SUBNET message). - this checking can be made before the check of the owner, especially before...

...edge propagation storms taking the entire network down. Recently we had a setup with a small number of "hubs" to which all the other nodes connected to, which limited the number of meta connections, but that didn't help much with the edge propagation issues. Now we moved to using the TunnelServer mode where we define all the necessary ConnectTos (on one side of the tunnel), which at least solves the propagation issues. There are a couple of servers where most of the servers still need to connect to and with TunnelServer mode we noticed that the throughput on those servers dropped to less t...

...he following is maybe a bug report, and a proposed patch. Using latest stable tinc 1.0.12. I have a central server and a few clients connecting to this server. I don't want clients to speak directly, but I want all the communications to pass by the server. My configuration is: Mode = switch TunnelServer = Yes I need layer2 because of some ethernet stuff on the clients. When you have these two things set up it happens that the tincd damon will ignore any Subnet add request, if not allowed in the configuration file. This means that, because tincd is working on L2, it will not learn the MAC address...

...nt to control which daemons can access other deamons. For the most part, I just want the server to be able to access each daemon and the subnets behind them but not have the daemons access each other or the subnets behind them. Everything currently connects through one central server initially, so TunnelServer seemed like the right configuration option. If I understand this setting correctly, it is meant to only allow traffic between nodes that have eachother's (or at least one has the other's) host file on the local system. However, after enabling TunnelServer, my test daemon can no longer ping...

...on to the server when TunnelMode is yes? check if this patch still applies: https://github.com/zioproto/fairvpn/blob/master/tarballs-patches/tinc/tinc-1.0.13-fairvpn.patch it should work. By default tinc will try to have a full mesh of connection between the nodes of the VPN. With this patch and TunnelServer yes you will have the data connections only where you have a explicit ConnectTo statement. regards Saverio

...Server with public IPv4 address: /etc/tinc/tinc.conf Name = devtun AddressFamily = ipv4 Interface = tuu0 Mode = router /etc/tinc/devtun/tinc-up #!/bin/sh ifconfig $INTERFACE 192.168.2.1/29 route add -net 192.168.0.0/24 gw 192.168.2.1 dev $INTERFACE /etc/tinc/devtun/hosts/devtun TunnelServer = yes Address = 10.0.10.3 Subnet = 192.168.2.1/32 -----BEGIN RSA PUBLIC KEY----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END RSA PUBLIC KEY----- * Note that I also tried putting in another "Subnet" for the 192.168.0.0 but it didn't seem to do anything. Com...

...inc itself... So, in zerotier all works fine? you still have flat (mesh) network design? Or you redesigned network aswell? ---------- Original message ---------- From: Anton Avramov <SRS0=7cKF=BG=lukav.com=lukav at mijnuvt.nl> To: tinc-devel at tinc-vpn.org Subject: Re: SegFault when using TunnelServer=yes Date: Mon, 27 Jul 2020 17:35:21 -0400 Hi, thank for getting back. I'll answer the questions, but I've already gave up on tinc and switch to zerotier-one. On 2020-07-27 5:10 p.m., borg at uu3.net wrote: > Hi. I have few questions out of curiosity.. Cant help for now with > your...

...so mesh links arent large.. I would NOT go beyond 30 nodes for full auto-mesh.. its already like 435 edges... Regards, Borg ---------- Original message ---------- From: Anton Avramov <SRS0=TSOC=AB=lukav.com=lukav at mijnuvt.nl> To: tinc-devel at tinc-vpn.org Subject: SegFault when using TunnelServer=yes Date: Fri, 19 Jun 2020 12:22:36 -0400 Hi all, I have a network with about ~800. The network is a mix of tinc 1.0 and 1.1 nodes. It is gradually expanding for several years now. The problem is that at some point it seams the daemon can not handle the processing of the new connection and the...

Thank you for the helpful advice. We will try to group the servers with different ConnectTo servers first. If this does not help we will look at the TunnelServer solution. Just to make sure we understand TunnelServer correctly: do you need to specify every host as ConnectTo that the host should be able to communicate with or is it sufficient to just provide the hosts files? Thanks, Hendrik 2016-06-21 14:35 GMT+02:00 Guus Sliepen <guus at tinc-vpn.org&g...

...tops working and only produces log messages about failed connection attempts)? Ideally we would not need any metadata updates at all (apart from key updates) since each host can connect to every other host and all the host config files are available everywhere locally. We also thought about using TunnelServer = yes, would this help? Does it make sense to somehow group ConnectTo hosts (so use two ConnectTo servers for one host group, another two for another host group and let the ConnectTo servers connect to each other)? Thank you for any help with this! Hendrik -------------- next part --------------...

...If A and EvilNode, have not exchanged public keys directly, they can still establish sockets with one another over their TINC IP addresses. I know if both node A and EvilNode ConnectTo B, then EvilNode can establish internet connections with node A's tinc IP. "Forwarding=OFF" or "TunnelServer=YES" or "IndirectData=NO" are supposed to prevent this. EvilNode can connect and establish a tinc IP connection to A. I have to assume this happens because of Forwarding=internal by default. "config get IndirectData" and "config get Forwarding" and "confi...

...too) start.bat-------------------------------tincd -n Empire-Network -D -d4 --bypass-security (Bypass is only currently because tis not working yet) ------------------------------Host behind Firewall config:-------------------------------------Name = EmpirePhoenix Interface = Tinc-Vpn Mode = switch TunnelServer = yes ConnectTo = DarkNoir ----------------------------------- It's host file---------------------------------Address = empirephoenix.dyndns.org Port = 1194 IndirectData = yes Subnet = 192.168.99.1 -----BEGIN RSA PUBLIC KEY----- blablabla -----END RSA PUBLIC KEY----- ---------------------------...

...: > > IP Range 10.100.0.2 to 10.100.127.255 > > > > Group 2: > > IP Range 10.100.128.1 to 10.100.255.255 > > > > Server IP: 10.100.0.1 > > I would recommend running two tinc daemons on the server, one for each > group. That way, you don't have to use TunnelServer and Forwarding = > kernel. > > > The problem is that I also need to isolate clients from group 1 from > > reaching the server, but found no way to do that yet. > > If you use two tinc daemons, and then for group 1, you can add > "DeviceType = dummy" to the serve...

...eave the connection is dead and reconnect again which in turns starts the hole process itself. In my opinion this is a design flaw in tinc. The notion to every node to know about every other nodes just limits how many nodes can be handled. In my case may be the situation could be mitigated with TunnelServer, but that leads to the crash, and further more would make for the other nodes to not be able to connect to each other. I think a better approach would be for the nodes to exchange information only when a link is to be established (something like arp). Like if node A want to contact node C but...

...p, but I sill > need to communicate clients from one group to the other. > > Clients from group 2 (admin group) need to reach clients from group 1 > (remote server group), but clients from group 1 must not be able to reach > each other nor the server. > > If I'm not using TunnelServer and Forwarding, How can I setup the routes > between the two Tinc daemons? For group 1, set TunnelServer = yes and Forwarding = off. This prevents clients from seeing and talking to each other. Also don't use DeviceType. Now that you have two VPN interfaces on the server, one for group 1 an...

...ons on the other 2 major nodes at some point there are rapid spikes in the edges when new connection is established. So my guess is that the other nodes have a previous state on the edges when they try to push it, that is causing the main nodes to become overwhelmed. So I've decided to put TunnelServer=yes on the major nodes so they don't propagate the connections on the other nodes. However I get a segfault soon after starting on each node that I enable that option. I've build from the latest code and here is a trace of such a run: (this is not from a "major" node, but the...

...2.16.1.1 Subnet = 172.16.1.0/24 Port = 6555 -----BEGIN RSA PUBLIC KEY----- Following the next line in the documentation: *the **tinc join**command on the client will automatically separate statements based on whether they should be in **tinc.conf** or in a host config file* We wanted to add “TunnelServer = yes” to the invitation hoping Tinc would know to put it into the tinc.conf file. But thinc told us it did not understand the parameter. Do we do something wrong, or are not all “experimental” features supported in the invitation files? Many thanks, Wouter Verstraeten -------------- next...

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

...ou Guillermo. I will give it a go and revert back with my results. Regards Yazeed Fataar <yazeedfataar at hotmail.com> On Mon, Feb 13, 2017 at 2:26 PM, Guillermo Bisheimer < gbisheimer at bys-control.com.ar> wrote: > Hi Yazeed, > > You have to add this to tinc.conf > > TunnelServer = yes > > Otherwise tinc will manage package routing internally. Then you can manage > forwarding rules using IPTABLES as usual. > > Hope it helps. > > > > El lun., 13 feb. 2017 a las 8:11, Yazeed Fataar (<yazeedfataar at gmail.com>) > escribió: > > Hi >...

...nch of nodes divided in two groups: Group 1: IP Range 10.100.0.2 to 10.100.127.255 Group 2: IP Range 10.100.128.1 to 10.100.255.255 Server IP: 10.100.0.1 Every client connects only to the server. In the server I have the following tinc.conf: Name = server AddressFamily = ipv4 Interface = tun0 TunnelServer = yes Forwarding = kernel ListenAddress = * 655 And using iptables I managed to isolate the clients in group 1 from seeing each other using the following rule: sudo iptables -A FORWARD -s 10.100.0.0/17 -d 10.100.0.0/17 -j DROP Group 1 and 2 can see each other but cilents from group 1 cannot. Th...