Age | Commit message (Collapse) | Author |
|
|
|
|
|
We only delete iptables rules if they really exist - if we try to delete a non-
existing rule a PermissionError exception is thrown.
We could either ignore the error code (that is what the old Vyatta code did),
or we check what we are doing beforehand.
|
|
|
|
Commit 6f87d8c9 ("ospf: T3757: support to configure area at an interface level")
did not allow the old way an area and netwokr was set-up as the if
expression was missing a check if 'area' was set in both the interface and the
ospf process.
|
|
|
|
FRR supports configuring either network prefixes per area, or assign an
interface to an area to participate in the routing process. This is already well
known from other venders and supported by FRR.
A valid VyOS OSPF configuration would then look like:
vyos@vyos# show protocols
ospf {
interface dum0 {
area 0
}
interface eth0.201 {
area 0
authentication {
md5 {
key-id 10 {
md5-key vyos
}
}
}
dead-interval 40
hello-interval 10
priority 1
retransmit-interval 5
transmit-delay 1
}
log-adjacency-changes {
detail
}
parameters {
abr-type cisco
router-id 172.18.254.201
}
passive-interface default
passive-interface-exclude eth0.201
}
|
|
pbr: T3702: Add rules match fwmark
|
|
default behavior
|
|
|
|
When removing bgp (vrf) instances the assigned VRF vni must be deleted from FRR
prior the removal of the bgp settings (T3734).
This is now done by moving the CLI command "set vrf name red vni 1000" to a
dedicated Python script with a priority higher then bgp.
|
|
|
|
isis: T3708: Fix errors in MTU calculation
|
|
|
|
|
|
|
|
|
|
|
|
Somehow we hit a priority inversion here as we need to remove the VRF assigned
VNI before we can remove a BGP bound VRF instance. Maybe move this to an
individual helper script that set's up the VNI for the given VRF after any
routing protocol (in our case this was triggered by running "make testc" when
building an ISO image by the bgp-rpki config).
|
|
This is a completing commit to a55585a833 ("frr: T2175: remove no longer
required loop when removing routing protocols") that was missed out
previously.
|
|
IKE dh-group defaults to 2 (modp1024).
|
|
|
|
|
|
isis: T3693: Adding IPv6 redistribution to ISIS
|
|
In this commit we add the ability to redistribute into
ISIS for IPv6 address family.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
(cherry picked from commit 7292631373ea50f9908796ef2eda32e672d1df2e)
|
|
Update/refresh of DNS records is now handled internally by Strongswan.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|