@rcit Is that still a relevant issue?

nothing added we would need.

@alkersan I think you need to create the link via Makefile in vyos-1x. At least I don't know of any possibility doing that within the xml.

Thanks for your response, did you test a newer image already? There was a lot of work done meanwhile.

@mario Did you manage to upgrade to 1.2 and if so, do you still have that issue?

https://github.com/vyos/vyos-1x/commit/d34fd745438951d55c5c4899b2b3c7bfa5d08026

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201909102147-amd64.iso or later

https://vyos.readthedocs.io/en/latest/vpn/wireguard.html

https://github.com/vyos/vyos-1x/commit/db07e6fa76d90eaf80a06729753fb89266437674

https://github.com/vyos/vyos-1x/commit/1017c8103f12ebd6db4f250d8a154571fff32db1
Will be available in tomorrows rolling release for testing. Documentation is underway.

The default keys can only be overwritten, named-keys can be removed.

I think encapsulate the udp based traffic into tcp is more than counter productive and makes it an easy DoS target.

Why not using ports higher 1024? Port 80 and 443 are so called privileged ports, not sure if that is really required. Port udp/80, udp/443 for instance may interfere in the future with QUIC.

That is listen port. endpoints are peer specific, if you have multiple peers on the same interface, each one has of course it's own endpoint if you want to initiate the connections. Otherwise, once the other peer connected to your gateway (assuming the handshake was successful), this information is taken from the header.

@trystan Listen or endpoint? The listen port had been limited to avoid issues with IANA assigned ports.
udp/80 or udp/443 might not m=be the best option anyway.

https://github.com/vyos/vyos-1x/commit/f7456361b5b94f3c69f8fa0f34f8bff0ef68f9aa

https://github.com/vyos/vyos-1x/commit/189ae4f7096abf7ca7100a4a31e038ce9e3e19c2

Confirmed, same issue in 1.2.2

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.

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.

To reproduce:

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

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?

@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

That will be a complete rewrite, since the interface name is now readable via VYOS_TAGNODE_VALUE, that affects get_config() quite a lot and will reduce the number of code line significantly. The flip side of the coin is, that the current code was running pretty reliable, so I will release small updates while adopting to see if I break anything configure outside of my test environment.

Duplicate: T1628

@c-po sorry was camping in a remote area without cell coverage. What's the way we go then? I'll look tomorrow, eventually Tuesday next week into the dhcp stuff.

Perfect, I think the dummy interface would be one which needs to be corrected before I can remove the class file entirely.

moved get functions into properties, for ifalias, macaddr and mtu to see how it works. If the old get_ function is being used, it prints a message to the console but still works. Will see how well that works.
https://github.com/vyos/vyos-1x/commit/0b9c894fcece6df553a89e42147768ce6efaf372

[e]ach network interface has a private key [...]

https://vyos.readthedocs.io/en/equuleus/contributing/vyos-api/interface-config.html#interface-config
https://vyos.readthedocs.io/en/latest/contributing/vyos-api/interface-config.html

I don't think it's a good idea, for several reasons.