similar to: site-site vpn setup..

So, for remote manageability of Tinc, we don't have any SNMP or REST like programmatic ways? If it is going to be CLI only, it is definitely not secure to manage and also not very convenient to manage programmatically. On Sun, Mar 25, 2018 at 1:44 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, Mar 24, 2018 at 02:16:20PM -0700, al so wrote: > > > > Is there

Just search online why in general that is insecure via CLI vs programmatic for first class automation.. there is a reason why snmp, rest, ... exist. On Thu, Mar 29, 2018 at 3:50 AM, Tomasz Chmielewski <mangoo at wpkg.org> wrote: > You've mentioned security issues in your previous email, but now you're > hopping to management issues. > > Have you tried Ansible, Chef or

There is a reason most NMS systems used SNMP in the past and REST apis past 7+ years. They don't use CLIs except toy Expect type scripts.. Not just security but better error handling and more. Good luck learning! On Thu, Mar 29, 2018 at 9:03 AM, Tomasz Chmielewski <mangoo at wpkg.org> wrote: > SNMP is mainly used for monitoring, not _server_ automation. > > Also, it's

Programmatic management with first class APIs is preferred for larger deployments.. On Mon, Mar 26, 2018 at 12:28 PM, Tomasz Chmielewski <mangoo at wpkg.org> wrote: > Could you elaborate on why CLI (SSH) managing is insecure? > > > Tomasz Chmielewski > https://lxadm.com > > > On 2018-03-27 04:23, al so wrote: > >> So, for remote manageability of Tinc, we

Al like any open-source or free sofware you need to put the leg work into what you want it to be. My company is actually creating something using TINC and we believe in it. If successful we'll be giving back to TINC monetarily in a big way to make TINC even better so if TINC isn't for you keep an eye on further developments in the future. Thanks, Rafael On Thu, Mar 29, 2018 at 12:03

automation refers to day to day vpn management from non-IT layman... not a geek running shell/ansible scrpits. On Thu, Mar 29, 2018 at 8:48 AM, al so <volkswak at gmail.com> wrote: > Just search online why in general that is insecure via CLI vs programmatic > for first class automation.. there is a reason why snmp, rest, ... exist. > > On Thu, Mar 29, 2018 at 3:50 AM, Tomasz

On Sat, Mar 24, 2018 at 02:16:20PM -0700, al so wrote: > > Is there any quickstart guide to setup site-to-site VPN using Tinc 1.1 > > pre-rel? You can find an example of a site-to-site VPN with four sites here: http://tinc-vpn.org/documentation/Example-configuration.html > > Assuming I have two routers at two sites running tinc vpn along with > > routing feature. If

This part I have to answer on-list: > On 29 Mar 2018, at 17:50 , al so <volkswak at gmail.com> wrote: > > automation refers to day to day vpn management from non-IT layman... not a geek running shell/ansible scrpits. Dear Also / Volk Swak TINC have it’s uses and place in the VPN environment. Perhaps you could/should consider https://pritunl.com/ <https://pritunl.com/> or

Could you elaborate on why CLI (SSH) managing is insecure? Tomasz Chmielewski https://lxadm.com On 2018-03-27 04:23, al so wrote: > So, for remote manageability of Tinc, we don't have any SNMP or REST > like programmatic ways? > > If it is going to be CLI only, it is definitely not secure to manage > and also not very convenient to manage programmatically. > > On

SNMP is mainly used for monitoring, not _server_ automation. Also, it's inherently insecure for anything else - only SNMPv3 offers any kind of encryption, and it's DES - 56 bit only, and you can easily brute-force it on an average computer. If you could provide some serious articles about why is CLI insecure, I'd be interested to read. Tomasz Chmielewski https://lxadm.com On

You've mentioned security issues in your previous email, but now you're hopping to management issues. Have you tried Ansible, Chef or Puppet for automation? It works well for hundreds of servers, different services and not just one kind of VPN. Tomasz Chmielewski https://lxadm.com On 2018-03-29 16:10, al so wrote: > Programmatic management with first class APIs is preferred for

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

Tinc 1.0 3 control masters Many service hosts Laptop (road warrior) The control masters have the public keys for the service hosts and the laptop so that they can join the network. How can I prevent the laptop user to connect additional boxes to the network? In my view he can simply add new 'foreign' hosts and specify connectTo to point to the laptop. As keys are exchanged automatically

Hi all, I am new to Tinc VPN and really would like to make full benefit of this implementation if possible. I would like to know whether I will be able to use Tinc to its full potential. My current setup is as follows, IPfire router/firewall(openvpn client) --->ISP(Internet)--->Amazon VPS(openvpn server). The ipfire router is behind a CARRIER-GRADE NAT, I am able to reach the network

Hello, I've got an AWS cloud and a local network. I'd like to setup an access from private EC2 instances to local network tinc server. There are two public EC2 instances with tinc server installed, other (private) EC2 nodes do not have tinc. http://imgur.com/tq84crc VPC subnet: 172.22/16 VPN subnet: 21.0.0/24 Source EC2 instance ip: 172.22.0.100 Tinc 1 ip: 172.22.0.101, 21.0.0.1 Tinc 2

Hey guys, Stumbled upon tinc a few days ago - looks great. I'm having trouble setting up a simple VPN between two machines that are unfirewalled, one is a physical machine and another is a local VM. I can connect to them via their existing LAN IPs and ping them without issue with < 1ms. 1) I have WinA (Windows host - existing LAN IP 192.168.137.1) and LinuxB (Linux host - existing LAN

I meant Tinc site-site VPN deployments in US business segments. Just references if any. On Tue, Mar 20, 2018 at 1:44 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Tue, Mar 20, 2018 at 12:53:55PM -0700, al so wrote: > > > Are there any Tinc deployments in the USA in Medium sized businesses and > > small Enterprises? > > Yes. However, VPNs are Virtual *Private*

Actually I was wrong on masquerading. I've set it up the other way to masquerade packets from tinc3 to the internet via tinc1/tinc2. Subnet = 172.31.0.0/16 is there for both tinc1 and tinc2 as well as route for tinc3. I can reach any private instance from tinc3. > the return packet from tinc3 should end up back at tinc1, not tinc2. I suspect tinc doesn't reply to the same node, but

Hi 'tinc users' I'm new whit tinc and this mail-list. I like to build a vpn over the internet between two sites in Holland and Germany. Are there some experience whit the performance (turn-a-round en bandwidth) of a link. I want to use it for a 1,5Mb connection. Greetings, Fred Krom. - Tinc: Discussion list about the tinc VPN daemon Archive:

On Fri, Dec 12, 2014 at 02:21:08AM -0500, md at rpzdesign.com wrote: > Oops, I got it to work only after putting the WAN on port 656 so it > did not interfere with port 655 for the LAN. You should not need to have two tinc daemons just because you have a WAN and a LAN interface. By default (ie, if you don't specify BindToAddress and/or BindToInterface), tinc listens on all interfaces,