Fixed in T3217
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Sep 7 2021
please refer to the PKI documentation at https://docs.vyos.io/en/latest/configuration/pki/index.html or https://blog.vyos.io/pki-and-ipsec-ikev2-remote-access-vpn about how the PKI feature is used.
You don't need line like "begin|end"
For example
set pki ca openvpn_vtun10 certificate 'MIIDSzCCAjOgAwIBAgIUEtkjCVKmZCwUeYLenoznpkxMeZswQ=='
I tested it on ESXi
Sep 6 2021
It seems some bug in KVM.
I still see this bug
VyOS 1.3.0-rc6 config
vyos@r4-1.3# run show conf com | match mac set interfaces macsec macsec1 address '10.0.0.2/30' set interfaces macsec macsec1 security cipher 'gcm-aes-128' set interfaces macsec macsec1 security encrypt set interfaces macsec macsec1 security mka cak 'f42e15acecc0c1634582bdd32429efdf' set interfaces macsec macsec1 security mka ckn '0ef5ebf77ba031e45ad270e9f80c804d500a2649789db1c87b751114f329e032' set interfaces macsec macsec1 source-interface 'eth1'
Works as designed. Note that the MACSec interface will only change its state to u/u after a successful key-exchange.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/999
Does it work if you grand the capabilities to the openvpn group in /etc/security/capability.conf?
Required migration script to set commands to proper AFI.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/998
We tested this on 1.4-rolling-202103040218 on our router, unfortunately as this is a production device I couldn't spend long diagnosing this. After upgrading the system image the device didn't come back up (I have layer 2 connectivity to the device via a VLAN on eth1 normally). So I logged in via our serial console and did a show interfaces
If to use modified Regex --regex \'^((eth|lan)[0-9]+|(eth)[0-9]v.+|(eno|ens|enp|enx).+)$\'
https://github.com/vyos/vyos-1x/blob/10814c4d3360598262e991e4b20768dfcde91d75/interface-definitions/interfaces-ethernet.xml.in#L17
Sep 5 2021
Sep 4 2021
Client should also enable "SLAAC"
Works as expected it seems https://serverfault.com/a/918480 and https://teamarin.net/2018/06/25/common-mistake-dhcpv6/
Duplicate of T3772
- The problem about DHCPv6 has been solved
- The communication problem has been solved
It seems that the problem is related to IPv6 MSS. When I set IPv6 MSS to 1280 and IPv4 MSS to 1452, the problem seems to disappear
Let me add a verify step…
Sep 3 2021
Crashes if replace-as is set without no-prepend (see "Unknown command: neighbor 192.0.2.1 local-as 300 replace-as"):
PR for equuleus https://github.com/vyos/vyos-1x/pull/994