It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

OpenVPN now runs as user openvpn with the above helper script. Please also test this new implementation, it will be in the rolling ISO which is building right now.

Persistent tunnel is a configuration option set interfaces openvpn vtun10 persistent-tunnel

i agree with allowing this.

@hagbard the private key should stay where its generated. But thats not the point. The point @zx2c4 and I are making, is each interface represent a diffrent Identity. There are only some special cases where you would need the same private key on two interface. Useally you would just add all peers that connect with the same publickey to the same interface. You only need a second interface if there is a second identity you want to assume. For example wg01 might be used to connect to your workplace and wg02 to a vpn service. In that case you would want peers in wg01 and wg02 to know you under different identities.

I can confirm this is still a problem in current rolling versions.

Hello @kruisdraad . I trying to reproduce this issue, but without success. Tunnel works.

set interfaces l2tpv3 l2tpeth1010 address '192.168.37.2/27'
set interfaces l2tpv3 l2tpeth1010 encapsulation 'ip'
set interfaces l2tpv3 l2tpeth1010 local-ip '2001:db8::2'
set interfaces l2tpv3 l2tpeth1010 peer-session-id '100'
set interfaces l2tpv3 l2tpeth1010 peer-tunnel-id '200'
set interfaces l2tpv3 l2tpeth1010 remote-ip '2001:db8::1'
set interfaces l2tpv3 l2tpeth1010 session-id '100'
set interfaces l2tpv3 l2tpeth1010 tunnel-id '200'

Can you provide show log tail 100 after creating l2tpv3?

I'm able to reproduce this bug.

The same, but on current (jessie):

reset=$(shopt -po noglob); set -o noglob
toks=( $( compgen -d -- "$cur" ) )
eval $reset

when eval is called, it expands to eval 'set -o noglob' which triggers _vyatta_op_run set -o noglob, which chokes on the input.
_vyatta_op_run was set up as alias for "set" in https://github.com/vyos/vyatta-op/blob/66753705b86a3d104dfe127d4dd2b904a54ab404/functions/interpreter/vyatta-op-run#L38

eval alias ${cmd:0:$pos}=\'_vyatta_op_run ${cmd:0:$pos}\'

due to "set" being part of the templates.

So there are 2 issues as I found out, I fixed one so far. `/opt/vyatta/sbin/vyatta-interfaces.pl``` has been fixed, if it's called with a bonding interface it doesn't care about hw-id as long as it's a bond member, otherwise the legacy code just continues as before.
That helps with config changes and a cold boot, reboot however brings in another issue. Before the system goes down it compares mac addresses and sorts them. bond is still active and 2 eth interface have the same mac which confuses `/lib/udev/vyatta_net_name```

/opt/vyatta/sbin/vyatta-interfaces.pl

Has nothing to do with your rewrite, it is the legacy code which sets up the ethernet interfaces. Bond runs first, after that comes ethernet and changes the mac address of the bond member interface and that's the issue.

Huh? Which perl script?

To reproduce:

@c-po vyos config does touch it via a perl script. I have a patch ready today for it.

As the bonding interface has been completely rewritten this should not be an issue as I do not touch underlaying interface MAC addresses

No worries, I checked it out, the issue still persists but is not easily fixable.

Well, it's not so much the technical implementation via cli. The private key gets exposed on the computer you generate it, then you transfer it to the vyos box, now you have a duplicate if the origin is not removed. It creates multiple points where you can get the private key. If you have that key and the connection is not secured via pre-shared key, you can decrypt the traffic easily. Or do i See that completely wrong?

Why not specify the keys or the key file location via CLI like other VPN implementations do it?

Here's the output of set -x redirected to a file when doing "ls <TAB>" as root.

@hagbard I no longer have the hardware the issue was found on, or anything else with identical interfaces to bond at the moment.

@zsdc Can you please provide a relevant config snippet? I won't have a system with 400 interfaces, but I try to measure the difference with 4 to see if it exponentially increases the boot time.

@mb300sd can you please test with the latest rolling image and see if the issue still exists?

@zx2c4 The private key stays on the system it is generated in a directory only accessible by the user who created it. Now when you create an interface let's say wg01 with 20 peers set up, you hand out 20 time the same public key and to decrypt the incoming traffic you use the single private key. Now, let's say you create an interface wg02, also with 20 peers. Why would it be better to generate a new key pair for wg02 on the same system and use a new private key just for that interface?

available via rolling releases
https://github.com/vyos/vyos-1x/blob/current/python/vyos/ifconfig.py#L1270
https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/interface-wireguard.py

@yun can you check this issue on last rolling release, I think it fixed.

That is great to hear, i will schedule upgrade of our infra soon and add some tunnels on GRE6. Ill report back when i have info

Hello, @kruisdraad!
IP6GRE tunnels are supported in 1.2-rolling-201909041703. You are welcome to test.

You could use quoting like mentioned in T1129.

Rewrite was tested using:

So in conf file should be enabled by default:
iproute /usr/local/sbin/unpriv-ip
persist-tun

As i understand this script only generate conf file, but we need to change init script, add wrapper script and grant sudo access to the openvpn user to exec this wrapper script...

I like the openvpn:openvpn ownership idea

The documentation is also correct. Please not that there are two git branches for the documentation, current and equuleus. You send me the VyOS 1.2.2 crux link. I gave you the upcoming VyOS 1.2 equuleus link.

Thanks, I'll try to figure it out. What do you think about openvpn:openvpn?

This is actually a duplicate of T1617.

Thanks! Should update the documentation @ https://vyos.readthedocs.io/en/latest/interfaces/bridging.html

I'm aware, I'm testing it since 1.2 has an unresolvable bug (due to the age of the distribution it's built on) in the isc-dhcp-relay package.

The bahavior has changed, see https://vyos.readthedocs.io/en/equuleus/interfaces/bridging.html and T1556

1.3 rolling is not recommended for users - its pre-alpha.

Just noticed you used VyOS 1.2-rolling-201909040337, this is for 1.3 rolling.

@jdevincentis is this a custom build? Using VyOS 1.2-rolling-201909040337 I can not reproduce the issue with: