[email protected]:~$ generate pki wireguard key-pair file test Private key: QG039BeDoy2MXKxQwFRhYYea7B50crYvZ1RUn+N0c3A= Public key: iXVG4GSHc0O7NHgX47DhhNO/WWSTZS83/eF2z4GHYSE= File written to /config/auth/test_public.key File written to /config/auth/test_private.key
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 9 2021
Sorry, I haven;t managed to test yet, due to some configuration migration errors leaving me unable to login. Will comment once I've confirmed though, most likely tomorrow.
Thanks, I got it working now.
Your problem is that this is not a CA certificate, it's the servers certificate.
Sep 8 2021
Can you share your CAs public cert for testing?
Hello, Sorry, but I tried this I get "Invalid certificate on CA certificate "test"
A new ISO 1.4-rolling-202109081242 is currently build - you may check in 30 minutes and try if this works for you - it did in my example config.
That would only work if accept_local will be added as proper CLI node on the tunnel interface, or use set system sysctl parameter net.ipv4.conf.default.accept_local value '1'
Certainly, here it is:
openvpn vtun0 { authentication { password ****** username ****** } encryption { cipher aes256 } hash sha512 mode client openvpn-option fast-io openvpn-option "remote-cert-tls server" openvpn-option "resolv-retry infinite" openvpn-option "pull-filter ignore redirect-gateway" openvpn-option "tun-mtu 1500" openvpn-option "tun-mtu-extra 32" openvpn-option "mssfix 1450" openvpn-option "comp-lzo no" openvpn-option "ping-restart 0" openvpn-option ping-timer-rem openvpn-option "ping 15" openvpn-option "reneg-sec 0" persistent-tunnel protocol udp remote-host xxx.xxx.xx.xxx remote-port 1194 tls { auth-key **************** ca-certificate *************** tls-version-min 1.2 } }
Sep 7 2021
Can you please share a version of your anonymized client configuration?
Unfortunately not. I reverted my changes and then added:
cap_dac_override,cap_setgid,cap_setuid,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_audit_write @openvpn
to /etc/security/capability.conf but got the same errors as before (I rebooted to make sure).
Same happens to other op-mode commands:
Fixed in T3217
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
[email protected]# 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