Hello,
there were no requests for this and no plans to implement this

i will try to do some work on implementing this if its possible to get it upstream if i succeed?

I already have a compiled version for for both 1.1.8 and 1.2.0 running , so its mostly packaging (src-)deb and developing the menu-system

I don't think it's necessary to compile DEB packages because they can be obtained directly from apt

So the problem is with configuration commands and py scripts

Maybe we can think about how to achieve it in the near future

The version of tinc vpn supplied with buster is 1.0.35, and 1.1-pre17 is only availabe in the experimental repository as for now. The first release of 1.1pre is from 2011 and i would say that it is quite mature at this point.

Another option is to compile and package by yourself, but the location of the repository is the problem

During the development phase, it can be placed in vyos-build/packages, but is this location really appropriate?

placing the tinc deb in vyos-build/packages is appropriate while writing support for tinc, but for building on a production iso that is distribute it is not appropriate.. but it's quite easy to add the package to our own repository if we need that...

other than that: ref. from slack:
the config difference on 1.0 and 1.1 is not that big, so adding a preliminary support for 1.0 and migrate that to 1.1 or 2.0 should not be that hard. as we now have get_config_dict most of the work could be done in the jinja templates

I wrote a preliminary CLI configuration file rule. This is the first step in tinc implementation. For details, please read: https://github.com/jack9603301/vyos-1x/blob/T766/interface-definitions/interfaces-tinc.xml.in

If you have other questions, please follow up

I am implementing tinc, but there is a problem I haven't figured out. Normally, in order for tinc to run, it must have a public key and a private key, and it happens that there will be a prompt for this generation command (ask where to save, etc), and it happens that the public key of the local node in the hosts directory is usually used together with some host configuration options. Is there a better way to implement it?

I think we could generate private/public keys using openssl instead of using the tinc utility to generate it... But i have not tested it

@runar The preliminary integration of tinc is basically completed, please see

PR: https://github.com/vyos/vyos-1x/pull/570

I updated pr. so far, tinc VPN cli will automatically generate the local node key file, such as the following code:

set interfaces tinc tinc0 node-name s1
set interfaces tinc tinc0 address 10.1.3.1/24
set interfaces tinc tinc0 subnets 10.1.3.0/24  # Host configuration option subnet, address segment declared out
set interfaces tinc tinc0 private-keyfile /config/tinc0/rsa_pri.key
set interfaces tinc tinc0 hosts-dir /config/tinc0/hosts
set interfaces tinc tinc0 local-address <your-hosts-address>  # Host configuration option address, the announced server address
set interfaces tinc tinc0 port <port> # Host configuration option port, the declared server port
set interfaces tinc tinc0 resolve-hostname

This configuration will automatically generate a host configuration file r1 under the directory /config/tinc0/hosts, and the generation process will be carried out automatically without user intervention

When connecting to the other party's network or connecting with the client, you must have the relevant configuration file of the other node and copy it to hosts-dir(The file name must be a node name)

Then use the following command to connect to the peer server:

set interfaces tinc tinc0 connect <peer-node-name>

You can also use the following command to directly establish a soft link (the given path must be local)

set interfaces tinc tinc0 connect <peer-node-name> conf-path <conf-path>

You can pull the host configuration in operation mode using the following command:

generate tinc tincN host-conf <user@service:/path>

Next questions:

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

Note: my test found that when the server is in switch mode, the client cannot Ping to the peer in routing mode (more tests may be needed)

Note: my test found that when the server is in switch mode, the client cannot Ping to the peer in routing mode (more tests may be needed)

This is quite by-design, as when changing from router mode to switch mode you change the encapsulation from ip in tinc to ip in ethernet in tinc(goes from routing ip's to routing mac adresses), so a mode change needs to be done on a tunnel "global" scale.

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

It seems that we need to think about it now

You can pull the host configuration in operation mode using the following command:

generate tinc tincN host-conf <user@service:/path>

This does not belong to a "Generate" command as its just scp. its much better to direct the user to manually copying the files to the correct directory with scp or any means necessary. as another note we CANT mandate that the user should have ssh access between his routers to make this work.

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

It seems that we need to think about it now

What information do you need access to from within op-mode?

What information do you need access to from within op-mode?

Since restarting tinc requires resetting the interface, it means that you may need to get all the configuration information to call the update function settings of the interface class

This does not belong to a "Generate" command as its just scp. its much better to direct the user to manually copying the files to the correct directory with scp or any means necessary. as another note we CANT mandate that the user should have ssh access between his routers to make this work.

It seems that your suggestion is to cancel the operation mode command

In T766#77850, @jack9603301 wrote:

What information do you need access to from within op-mode?

Since restarting tinc requires resetting the interface, it means that you may need to get all the configuration information to call the update function settings of the interface class

I still dont know why you need to access this information from within op-mode, the interface will be reset while in conf-mode by the conf mode script.

Tinc 1.1 supports rereading a lot of the configuration without resetarting the daemon, i've compiled a version of 1.1 for you from the debian salsa repository: https://salsa.debian.org/guus/tinc/-/tree/1.1/debian (this is whats available in the experimental debian branch) the deb is available her for now: https://borge.nu/vyos/tinc_1.1~pre17-1.1_amd64.deb. just put it in the packages directory when you're generating the iso or dpkg -i it into a image that have tinc-1.0 allready.

This does not belong to a "Generate" command as its just scp. its much better to direct the user to manually copying the files to the correct directory with scp or any means necessary. as another note we CANT mandate that the user should have ssh access between his routers to make this work.

It seems that your suggestion is to cancel the operation mode command

thats correct.

Tinc 1.1 supports rereading a lot of the configuration without resetarting the daemon, i've compiled a version of 1.1 for you from the debian salsa repository: https://salsa.debian.org/guus/tinc/-/tree/1.1/debian (this is whats available in the experimental debian branch) the deb is available her for now: https://borge.nu/vyos/tinc_1.1~pre17-1.1_amd64.deb. just put it in the packages directory when you're generating the iso or dpkg -i it into a image that have tinc-1.0 allready.

I'll try your tinc 1.1 tomorrow

@runar Some interesting commands, such as tinc - n netname join URL, seem to be supported in tinc1.1

This means that I can design shortcut commands to join the network in the operation mode. What operation mode command path do you think should be placed??

The tinc - n netname invite name command is also supported for inviting users

Hello everyone, I am integrating tinc. At present, I have passed the basic test in a simple virtual machine. The command line is simplified. Examples are as follows:

set interfaces tinc tinc0 node-name s1 # require
set interfaces tinc tinc0 address 10.1.3.1/24 # require
set interfaces tinc tinc0 subnets 10.1.3.1/32  # require,Host configuration option subnet, address segment declared out
set interfaces tinc tinc0 local-address <your-hosts-address>  # Host configuration option address, the announced server address
set interfaces tinc tinc0 port <port> # Host configuration option port, the declared server port

Then use the following command to connect to the peer server:

set interfaces tinc tinc0 connect <peer-node-name>

You can also use the following command to directly establish a soft link (the given path must be local)

set interfaces tinc tinc0 connect <peer-node-name> conf-path <conf-path>

You can pull the host configuration in operation mode using the following command:

sudo cp /config/tinc0/hosts/s1 s1
sudo chown vyos s1
sudo scp s1 vyos@ip:~/s1

After entering the other party's server, execute:

sudo cp s1 /etc/tinc/tincN/hosts/s1

In general, it can work normally. Use the following operation mode commands to overload the configuration:

reset tinc tincN

Note that vyos tinc support is based on tinc 1.1 instead of 1.0

Which files in /config/tinc0/hosts ?

set interfaces tinc tinc0 connect <peer-node-name> conf-path <conf-path>

It the same as..

set interfaces tinc tinc0 peer x.x.x.x

What content of "conf-path" ?
Can you show real example with established vpn?
Configuration from both sites with all related directories/configs/etc

Can we configure romte site without scp? For example if remote site in Azure and we doesn't have access to it. Access only for client on remote site.

What content of "conf-path" ?

This command is actually to create a soft link, usually you don’t need to specify it, but you need to put its file in the hosts path

Normally, if you have put the files in the correct path yourself, then you only need to:

set interfaces tinc tinc0 connect <peer-node-name>

Can you show real example with established vpn?

The format of this file is roughly:

Subnet = <subnet>
Address = <service_address>
Port = 655
-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----
Ed25519PublicKey =

So I have no way to separate the options. If the other party's server allows you to establish a connection, then the other party should provide you with the host configuration file of its own server, and you only need to copy it to the appropriate path (no matter what method you take), the same, You need to give your host definition file (it will be automatically generated) to the other party (similar to signing an agreement). If a third party needs to establish a connection with you through the network, then he also needs to obtain your public key and host definition file

It has passed the GNS test, and the test cases are as follows:

r1

set interfaces bridge br1 address 'fc00:1::1/64'
set interfaces bridge br1 member interface eth0
set interfaces bridge br1 member interface eth1
set interfaces ethernet eth0 hw-id '0c:e8:e9:b9:63:00'
set interfaces ethernet eth1 hw-id '0c:e8:e9:b9:63:01'
set interfaces ethernet eth2 hw-id '0c:e8:e9:b9:63:02'
set interfaces ethernet eth3 hw-id '0c:e8:e9:b9:63:03'
set interfaces loopback lo
set interfaces tinc tinc0 address 'fc00:4::1/64'
set interfaces tinc tinc0 local-address 'fc00:1::1'
set interfaces tinc tinc0 node-name 'r1'
set interfaces tinc tinc0 subnets 'fc00:4::1/128'
set interfaces tinc tinc0 subnets 'fc00:1::/64'
set protocols ospfv3 area 0 interface 'br1'
set protocols ospfv3 area 0 range fc00:1::/64
set protocols ospfv3 parameters router-id '1.1.1.1'
set protocols ospfv3 redistribute connected
set service router-advert interface br1 prefix ::/0
set service ssh listen-address '::'
commit

r2:

set interfaces bridge br1 address 'fc00:2::1/64'
set interfaces bridge br1 member interface eth1
set interfaces ethernet eth0 address 'fc00:1::2/64'
set interfaces ethernet eth0 hw-id '0c:e8:e9:63:1e:00'
set interfaces ethernet eth1 hw-id '0c:e8:e9:63:1e:01'
set interfaces ethernet eth2 hw-id '0c:e8:e9:63:1e:02'
set interfaces ethernet eth3 hw-id '0c:e8:e9:63:1e:03'
set interfaces loopback lo
set protocols ospfv3 area 0 interface 'eth0'
set protocols ospfv3 area 0 interface 'br1'
set protocols ospfv3 area 0 range fc00:2::/64
set protocols ospfv3 parameters router-id '1.1.1.2'
set protocols ospfv3 redistribute connected
set service ssh
commit

r3:

set interfaces bridge br1 address 'fc00:3::1/64'
set interfaces bridge br1 member interface eth1
set interfaces ethernet eth0 address 'fc00:2::2/64'
set interfaces ethernet eth0 hw-id '0c:e8:e9:8c:9f:00'
set interfaces ethernet eth1 hw-id '0c:e8:e9:8c:9f:01'
set interfaces ethernet eth2 hw-id '0c:e8:e9:8c:9f:02'
set interfaces ethernet eth3 hw-id '0c:e8:e9:8c:9f:03'
set interfaces loopback lo
set interfaces tinc tinc0 address 'fc00:4::2/64'
set interfaces tinc tinc0 node-name 'r3'
set interfaces tinc tinc0 subnets 'fc00:4::2/128'
set interfaces tinc tinc0 subnets 'fc00:3::/64'
set protocols ospfv3 area 0 interface 'eth0'
set protocols ospfv3 area 0 interface 'br1'
set protocols ospfv3 area 0 range fc00:3::/64
set protocols ospfv3 parameters router-id '1.1.1.3'
set protocols ospfv3 redistribute connected
set protocols static route6 fc00:1::/64 next-hop fc00:4::2
set service router-advert interface br1 prefix ::/0
set service ssh listen-address '::'
commit

Copy Host Configure:

r1

scp vyos@[fc00:3::1]:/config/tinc/tinc0/hosts/r3 /config/tinc/tinc0/hosts/r3

r3

scp vyos@[fc00:1::1]:/config/tinc/tinc0/hosts/r1 /config/tinc/tinc0/hosts/r1

The official upstream address is https://gitlab.com/gsliepen/tinc , no Debian package generation rule file

For reference https://salsa.debian.org/guus/tinc.git But the following patches are required:

diff --git a/debian/postinst b/debian/postinst
index e05f787..1501922 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -2,10 +2,15 @@
 
 NETSFILE="/etc/tinc/nets.boot"
 
+NETSFILE_CONF="/etc/tinc"
+
 set -e
 
 case "$1" in
     configure)
+    if [ ! -e $NETSFILE_CONF ] ; then
+        mkdir $NETSFILE_CONF
+    fi
 	if [ ! -e $NETSFILE ] ; then
 	    echo "## This file contains all names of the networks to be started on system startup." > $NETSFILE
 	fi

It is suggested that vyos establish its own repo to build DEB and track the upstream version updates

Maybe it's better than the upstream patching script in vyos-build

Hi, I found that the transmission speed of tinc seems very disappointing, even in some cases, even the normal network communication has problems..