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.