similar to: How does tinc behavior when entry node shut down?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm trying to make a VPN network with the help of my friends. Tinc seems to support multiple connect to options, but isn't it tricky? Will it cause unsynchronized hosts etc? Will the 1.1 invite support it? PS: every nodes are not 24/7 on, maybe a node will be online but another not. - -- Sent from my Android device with K-9 Mail. Please

I don't know.. It seems that anyone had try to made work tinc with lollipop. Even googoling i don't found anything about this argoument. Andrea Squeri Il 27/mar/2015 06:55 "Tatsuyuki Ishi" <ishitatsuyuki at gmail.com> ha scritto: > SELinux is considered as the biggest problem. > > On Thu, Mar 26, 2015, 22:37 Andrea Squeri <andrea.squeri at gmail.com>

I switch to lollipop 4 months ago and I never had issue. So for my opinion it is ready for daily use. Before try tinc I had my vpn implemented with openvpn, and it works great on lollipop. I switch to tinc because i prefer a mash vpn topology versus a client/server topology. -- Andrea Squeri Inviato con Sparrow (http://www.sparrowmailapp.com/?sig) Il giorno venerd? 27 marzo 2015, alle ore

Thanks for reply.. I'll try and then i'll advise you if it woks Andrea Squeri Il 30/mar/2015 11:38 "Vil Brekin" <vilbrekin at gmail.com> ha scritto: > Hi there, > > I've finally had a deeper look and found the Lollipop routing issues root > cause: Lollipop uses several routing tables instead of the default one for > previous Android versions. The main

I think it's more of a routing issue than anything explicitly blocking it, they use a new 'ip rule list' and per user settings that aren't well documented yet either, but where exactly to point I don't know. I haven't messed with android 5 much yet, it seems not ready enough yet for daily use, there isn't a single snapshot in the cyanogenmod repos, for example. So maybe

Hi I have not tried systemd-coredump yet but I found something strange in my syslog file. Like this message in the en of the log file: tincd[10322]: segfault at 7fffb3180000 ip 00007ff7937f11c2 sp 00007fffb317dd68 error 4 in libc-2.23.so[7ff7936a3000+1c0000] There is more in the attached syslog file. Any clues? Best Regards, Håvard Rabbe > On 14 Feb 2019, at 02:27, Hamish Moffatt

On Mon, Feb 22, 2016 at 05:41:05PM +0300, Yazeed Fataar wrote: > Ok I have a simple lab setup with three nodes , one acting as the "Central > Node" and the other two as remote nodes which "*ConnectTo*" the central > node in order to be able to communicate with each other. > > What I would like to know is , once the tinc remote nodes establish a > connection

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

Hi, I am using tinc version 1.1pre10, and I am generating the key file using command below ... /usr/local/sbin/tinc -n myvpn init hostname In some of the host file I am seeing a new line "Port = 29732" added at the end of the host key file... /etc/tinc/myvpn/hosts/hostname Port = 29732 this line Port = 29732 is causing tinc to break. It all works fine once I manually delete the

Hi there, I've finally had a deeper look and found the Lollipop routing issues root cause: Lollipop uses several routing tables instead of the default one for previous Android versions. The main routing table is used with lowest priority per default: root at hammerhead:/ # ip rule show 0: from all lookup local 10000: from all fwmark 0xc0000/0xd0000 lookup legacy_system 13000: from all

On Wed, May 03, 2017 at 02:15:36PM +0800, Bright Zhao wrote: > 1. The destination of IPv4 wouldn’t be changed, Yes I agree, that’s the goal and final destination for the communication. But during the path, it may be encapsulated into another packet(tunnel mode), where the outside IP header is the physical address, but the inner destination remain unchanged, and I think Tinc encapsulates into

Hello list, we have been running tinc to connect multiple nodes without problems for quite some time now. Thanks for this great piece of software! Our configuration is as follows: Two "supernodes" A and B running the tinc daemon are publicly reachable from the internet. Node A is running Linux and has a static public IP address. Node B is running Windows with port forwarding

Hi, Guus I don’t quite understand what you describe below, to me, no matter tinc or any other router/PC get an IP packet, it will go to check with its route table, to match the destination IP against the route table for the next hop, if I put "ip route add default via <C’s VPN IP address> dev $INTERFACE", I thought tinc will match the packet’s destination IP to the “default”, and

Hello List, I have this setup: hosta  <--> hostb  <-->  hostc Hosta and hostc are not directly connected via tinc. But both are conncted via hostb (I called my network tincnet). This works fine I can ssh from hosta to hostc and vice versa without any problems. hostc is in a whitelisted iprange at some service provider. I need hosta to talk to a certain ip (lets call it

On 6 April 2015 at 15:56, Vladimir "Equidamoid" Shapranov <equidamoid at gmail.com> wrote: > Looks like some issue in tuntaposx that prevents the interface from work > until a packet is sent to it. Nope. The issue is that tinc is currently not smart enough to directly read the MAC address of the TAP device for BSD-style devices (of which tuntaposx is one). Therefore you need

Hi, Tinc experts There’s a requirement, where A connect to B, B connect to C; where B knows all the subnets from A and C, but A wouldn’t need to know anything about C, and C wouldn’t need to know anything about A. Any tinc configuration can make this happen? You can think of B is not an interconnect/forwarding node, instead, it only connect to A and C separately. I can think of run two tinc

On Tue, May 02, 2017 at 09:16:53AM +0800, Bright Zhao wrote: > In this case, A's traffic route to Internet is go through C to D to internet, but If I add Subnet =0.0.0.0/0 on B, the traffic seems go directly from A to B to internet. [...] > During the whole process, A's default gateway point to C. It might look that way, but it doesn't. I assume you did something like this on

Hi Ok I have a simple lab setup with three nodes , one acting as the "Central Node" and the other two as remote nodes which "*ConnectTo*" the central node in order to be able to communicate with each other. What I would like to know is , once the tinc remote nodes establish a connection to the "Central Node" , my understanding was that if the remote nodes want to

On Sat, May 16, 2015 at 12:09:52AM +0200, Sven-Haegar Koch wrote: > This change is not so good: > > Connection with aaa_vpnhub1 (1.2.3.4 port 443) activated > Error while translating addresses: ai_family not supported > > (And then the tinc process exists) Hm, I couldn't reproduce it, but I committed a fix anyway that makes sockaddr2str() handle AF_UNSPEC addresses. It

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