Age | Commit message (Collapse) | Author |
|
|
|
For more information see:
* https://programmersought.com/article/62242485344/
* https://www.spinics.net/lists/netdev/msg332453.html
* https://github.com/FRRouting/frr/blob/master/doc/user/Useful_Sysctl_Settings.md
|
|
Recommended by FRR best deafults
https://github.com/FRRouting/frr/blob/master/doc/user/Useful_Sysctl_Settings.md
|
|
configd: T3694: always set script.argv
|
|
Commit f520182b ("vyos.util: add is_systemd_service_running() helper function")
added a new helper function that can be used to check if a systemd service is
running.
Drop all custom implementations in favor of this library call.
|
|
Several scripts imported by vyos-configd (including
src/conf_mode/protocols_static.py) rely on argv for operating on VRFs.
Always setting script.argv in src/services/vyos-configd ensures those
scripts will operate on the default VRF when called with no arguments.
Otherwise, a stale argv might cause those scripts to operate on the last
modified VRF instead of the default VRF.
|
|
|
|
|
|
|
|
$ generate ipsec mac-ios-profile <connection> remote <ip>
|
|
The migrator from 20-to-21 is required as 19-to-20 on VyOS 1.3 - thus simply
rename/reorder the two migrators to not break things the hard way when
upgrading from 1.3 -> 1.4.
|
|
|
|
set vpn ipsec remote-access connection rw authentication client-mode 'eap-radius'
set vpn ipsec remote-access connection rw authentication id '192.0.2.1'
set vpn ipsec remote-access connection rw authentication server-mode 'x509'
set vpn ipsec remote-access connection rw authentication x509 ca-certificate 'CAcert_Class_3_Root'
set vpn ipsec remote-access connection rw authentication x509 certificate 'vyos'
set vpn ipsec remote-access connection rw esp-group 'ESP-RW'
set vpn ipsec remote-access connection rw ike-group 'IKE-RW'
set vpn ipsec remote-access connection rw local-address '192.0.2.1'
set vpn ipsec remote-access connection rw pool 'ra-rw-ipv4'
set vpn ipsec remote-access connection rw unique 'never'
set vpn ipsec remote-access pool ra-rw-ipv4 name-server '192.0.2.2'
set vpn ipsec remote-access pool ra-rw-ipv4 prefix '192.168.22.0/24'
set vpn ipsec remote-access radius nas-identifier 'fooo'
set vpn ipsec remote-access radius server 172.16.100.10 key 'secret'
|
|
As this is only related to remote-access, keeping it under "options" simply
feels wrong.
|
|
pki: T3642: Add ability to write generated certificates/keys to files
|
|
|
|
(cherry picked from commit 7292631373ea50f9908796ef2eda32e672d1df2e)
|
|
filenames
|
|
As the keys are now stored inside the CLI configuration and no longer in a file
on the filesystem, this command is no longer required.
Also there are dedicated CLI commands available to display the additional
Wireguard information.
- show interfaces wireguard wg10
- show interfaces wireguard wg10 summary
|
|
Update/refresh of DNS records is now handled internally by Strongswan.
|
|
|
|
|
|
generate ipsec mac-ios-profile <connection> remote <ip|fqdn>
will generate a matching IPSec profile which can be loaded on an iOS device.
|
|
|
|
|
|
|
|
|
|
This extends commit 22791e26 ("VRF: T3655: proper connection tracking for VRFs")
so that when the netfilter table is removed, we first check if it exists at all,
and if it does not exist we do not remove it.
This fixes the smoketest error:
PermissionError: [Errno 1] failed to run command: nft delete table inet vrf_zones
|
|
pki: wireguard: T3642: Migrate Wireguard private key directly into CLI
|
|
|
|
Also renames peer pubkey to public-key for consistency
|
|
Remote access IP pools can now be defined at a global level and referenced
in IPSec remote-access connections. To defined a pool use:
set vpn ipsec remote-access pool global-ipv4 name-server '172.16.1.1'
set vpn ipsec remote-access pool global-ipv4 prefix '192.168.0.0/24'
set vpn ipsec remote-access pool global-ipv6 name-server '2001:db8::1'
set vpn ipsec remote-access pool global-ipv6 prefix '2001:db8:1000::/64'
A connection can then reference the pool:
set vpn ipsec remote-access connection foo pool 'global-ipv4'
set vpn ipsec remote-access connection foo pool 'global-ipv6'
|
|
... this enables a dual-stack IKEv2 VPN deployment.
|
|
|
|
|
|
|
|
|
|
VRF: T3655: proper connection tracking for VRFs
|
|
Currently, all VRFs share the same connection tracking table, which can
lead to problems:
- traffic leaks to a wrong VRF
- improper NAT rules handling when multiple VRFs contain the same IP
networks
- stateful firewall rules issues
The commit implements connection tracking zones support. Each VRF
utilizes its own zone, so connections will never mix up.
It also adds some restrictions to VRF names and assigned table numbers,
because of nftables and conntrack requirements:
- VRF name should always start from a letter (interfaces that start from
numbers are not supported in nftables rules)
- table number must be in the 100-65535 range because conntrack supports
only 65535 zones
|
|
Commit 22739144 ('ipsec: T2816: migrate "ipsec interfaces" to "interface"')
by accident deleted the vpn_ipsec.py Python handler.
Handler was restored.
|
|
This reverts commit c414479fdf1d5ad77170f977481fb9197c9559ae.
This commit broke the smoketests and also OpenVPN complains:
Options error: You must define certificate file (--cert) or PKCS#12 file (--pkcs12)
|
|
|
|
|
|
update to use PKI.
|
|
dhclient is already handled by netplug so it's removed to avoid double
renewing of dhcp leases.
|
|
|
|
|
|
This makes the tls cert-file and key-file optional and allows for more
advanced configurations via "openvpn-option", such as pkcs11 or pkcs12
options.
|
|
|
|
Previously during migration if one had used interface routes, the VRF based
ones got not migrated.
The following "old" VyOS 1.3 configuration did not get migrated:
set protocols static interface-route 10.20.0.0/24 next-hop-interface eth2 next-hop-vrf 'blue'
set protocols static interface-route 10.30.0.0/24 next-hop-interface br10 next-hop-vrf 'red'
set protocols vrf blue static interface-route 10.0.0.0/24 next-hop-interface eth1 next-hop-vrf 'default'
set protocols vrf red static interface-route 10.0.0.0/24 next-hop-interface eth1 next-hop-vrf 'default'
set vrf name blue table '3000'
set vrf name mgmt table '1000'
set vrf name red table '2000'
It must get migrated to:
set protocols static route 10.20.0.0/24 interface eth2 vrf 'blue'
set protocols static route 10.30.0.0/24 interface br10 vrf 'red'
set vrf name blue protocols static route 10.0.0.0/24 interface eth1 vrf 'default'
set vrf name blue table '3000'
set vrf name mgmt table '1000'
set vrf name red protocols static route 10.0.0.0/24 interface eth1 vrf 'default'
set vrf name red table '2000'
|