| Age | Commit message (Collapse) | Author |
|---|
|
In large networks with many zones where simple allow/deny rules are not sufficient,
zones become tedious to manage. Many use cases can be simplified by providing an
ability to define a default ruleset for traffic from other zones. This change proposes
adding the follwing syntax:
set firewall zone <name> default_firewall name <name>
set firewall zone <name> default_firewall ipv6_name <name>
The proposed behavior is the following:
local in:
The default firewall ruleset for the local zone will be appended after all
from configurations.
local out:
If a non-local zone does not have a from local ruleset but does have a
default_firewall ruleset, the default_firewall ruleset will be appended using
oifname
forward:
The default firewall ruleset for the zone will be appended after all from
configurations
To keep the behavior consistent with from ruleset configurations, a return is appended
after the default_firewall ruleset.
The proposed behavior differs slightly from the default_policy configuration for the
local out chains. The default_policy applied in the out templates comes from the local
zone, not the actual outbound zone. The proposed change does not amend this, but does
make default_firewall logically consistent with the intent of the out rules.
|
|
Execute commands for vpp sflow with API calls. Use values for polling interval and sampling rate from 'system sflow'. Add op-mode command
|
|
T7750: VPP: CGNAT commit failure with vpptunX interface
|
|
Allow using bond interfaces in CGNAT. Improve interface cleanup to rely
on VPP API queries, as VPP config changes may modify interface indexes
|
|
Co-Authored-By: Christian Breunig <christian@breunig.cc>
|
|
* Added 'protocol failover' to 'set vrf name':
set vrf name red protocols failover route 10.11.0.110/32 next-hop 10.0.0.2
* Added vrf and interface to target:
set ... next-hop 10.0.0.2 check target '10.120.0.21' vrf blue
set ... next-hop 10.0.0.2 check target '10.120.0.21' interface eth1
Last two are needed when check VRF is not same as route VRF.
In this case icmp can use any/both options, tcp requires `vrf` and
arp requires `interface`
|
|
This reverts commit d871fe9c4c65de87232802ed54b263c9b2824391.
|
|
Add TLS support for remote syslog by extending the CLI and backend to support configuration of CA certificates, client certificates, keys, and authentication modes.
This update integrates with the PKI subsystem for certificate management, ensures proper validation of protocol settings when TLS is enabled, and generates secure rsyslog configuration for forwarding logs over TLS.
|
|
De-hardcode plugin path allows starting VPP on different ARCHs
|
|
bgp: T7760: remove per vrf instance system-as node
|
|
|
|
firewall: T7475: Add an option to disable conntrack for individual firewall chaisn
|
|
frr_exporter: T7851: export IPv6 BGP sessions
|
|
T7773: VPP move crypto engines to crypto-engines template section
|
|
VPP 25.06 introduces a new format for crypto engines configuration
https://github.com/FDio/vpp/commit/f479eeb76
Update the template to account for this change.
|
|
|
|
T7842: VPP add pppoe enable-pass-nd-and-dhcpv6 option
|
|
T7805: VPP remove unused 'default-hugepage-size' from memory section and restrict page sizes in xml
|
|
T7787: add deprecation warning for ssh-dss keys
|
|
|
|
restrict page sizes in xml
|
|
T7796: PPPoE-server add mapping in vpp if vpp-cp is enabled
|
|
wlb: T114: Add firewall group support for WAN load balancer
|
|
OpenSSH in Debian Trixie has removed support for ssh-dss (DSA) keys, which will
prevent users with such keys from logging in after upgrade. To avoid lockouts,
add a loud deprecation warning when users log in using a DSA key. This warning
advises affected users to replace their keys with a supported algorithm (e.g.,
ed25519 or RSA) before the upgrade.
Deprecation warning will be displayed during "commit" but also as MOTD to inform
on this issue during every login.
DEPRECATION WARNING: Support for SSH-DSA keys is deprecated and will
be removed in VyOS 1.6. Please update affected keys to a supported
algorithm (e.g., RSA, ECDSA or ED25519) to avoid authentication
failures after the upgrade. The following hostkey-algorithms are in
use: ssh-dss, ssh-dss-cert-v01@openssh.com
|
|
OpenSSH in Debian Trixie has removed support for ssh-dss (DSA) keys, which will
prevent users with such keys from logging in after upgrade. To avoid lockouts,
add a loud deprecation warning when users log in using a DSA key. This warning
advises affected users to replace their keys with a supported algorithm (e.g.,
ed25519 or RSA) before the upgrade.
Deprecation warning will be displayed during "commit" but also as MOTD to inform
on this issue during every login.
DEPRECATION WARNING: Support for SSH-DSA keys is deprecated and will
be removed in VyOS 1.6. Please update affected keys to a supported
algorithm (e.g., RSA, ECDSA or ED25519) to avoid authentication
failures after the upgrade. The following users are using SSH-DSS keys
for authentication.
User "vyos" with deprecated public-key named: foo
|
|
|
|
T75: migrate from pmacct to ipt_NETFLOW
|
|
firewall: T7452: update rule generation for Zone-based firewall
|
|
* Change nft to iptables in system_flow-accounting.py as ipt_NETFLOW
is iptales plugin
* Remove specific and non-relevant pmacct options
* Add ipt_NETFLOW options
* Move 'interfaces' to 'netflow' tree
* Support more flexible 'source-address' and 'source-interface' for
each server instead of one source
* Add migration script
* Update op mode command 'show flow-accounting'
* Update op mode command 'restart flow-accounting'
|
|
T7682: incorrect sla-len in DHCPv6 client prefix delegation (DHCPv6-PD)
|
|
- Added 'rpki-extcommunity' match condition
- Added test to test_policy.py smoketest for rpki-extcommunity match
|
|
|
|
The current template has an overly optimistic logic for sla-len calculation,
relying on an assumption that a server always provides a prefix with the exact
length requested by the client. This is incorrect. According to RFC8415 and
RFC7084, the prefix length in a request is only a hint for the server, which
may decide to provide a different prefix size.
The big issue here is that wide-dhcpv6-client uses the sla-len value from the
configuration regardless of the received prefix size. This seems to be the
known issue.
The good news is that we have already inherited a patch from Debian to mitigate
the issue [1]. It accomplishes exactly what we are doing in the configuration
template, but with the advantage of using the actual prefix length from the
received prefix, rather than the one configured in the configuration file.
If we simply remove sla-len from the template, everything appears to function
normally.
Before - server sending /56
set interfaces ethernet eth1 address 'dhcpv6'
set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth2 address '1'
set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth2 sla-id '0'
set interfaces ethernet eth1 dhcpv6-options pd 1 length '60'
Resulted in:
vyos@vyos# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description
----------- ------------------- ----------------- ------- ----- ----- -------------
eth1 fc00:0:0:1::200/128 0c:67:94:67:00:01 default 1500 u/u
eth2 fc00:0:2:ff00::1/60 0c:67:94:67:00:02 default 1500 u/u
Whereas IPv6 PD should always use a /64 prefix on the interface we assign a
dynamic DHCPv6 prefix to.
After the fix:
vyos@vyos:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description
----------- ------------------- ----------------- ------- ----- ----- -------------
eth1 fc00:0:0:1::200/128 0c:67:94:67:00:01 default 1500 u/u
eth2 fc00:0:2:ff00::1/64 0c:67:94:67:00:02 default 1500 u/u
If a DHCPv6 server (e.g. VyOS itself) even provides multiple PD prefixes, the
right one is choosen. Assume the following server configuration:
set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 address-range start fc00:0:0:1::100 stop 'fc00:0:0:1::200'
set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 lease-time default '120'
set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 prefix-delegation start fc00:0:2:: prefix-length '56'
set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 prefix-delegation start fc00:0:2:: stop 'fc00:0:2:ff00::'
set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 prefix-delegation start fc00:0:3:: prefix-length '60'
set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 prefix-delegation start fc00:0:3:: stop 'fc00:0:3:ff00::'
If a /56 is requested ("dhcpv6-options pd 1 length 56") - we will get a per
interface /64 from the original /56 prefix-delegation from the DHCPv6 server.
If the user suddently requests a /60 ("dhcpv6-options pd 1 length 60") the
delegated prefix will be from the above fc00:0:3:: pool.
1: https://salsa.debian.org/debian/wide-dhcpv6/-/blob/debian/20080615-23/debian/patches/0021-Make-sla-len-config-optional.patch
|
|
conntrack: T7700: Prevent empty policy generation
|
|
ospf: T7297: fix redistribute-table
|
|
Only print policy in nftables-ct.conf if protocol config is defined
|
|
|
|
Originating from the bug in T7665. To avoid potential issues down the line - and
given that there's no compelling technical reason to retain the system-as CLI
node under per-VRF BGP configuration, which cannot be achieved through
alternative means - the maintainers have collectively decided to deprecate the
following command:
set vrf name <name> protocols bgp system-as <asn>
Starting with VyOS 1.4.4, this CLI command will be considered deprecated. While
it will still be accepted, it will no longer have any operational effect. A
deprecation warning will be displayed at commit time, indicating that the BGP
ASN from the global BGP configuration is now used instead.
A migration script will handle the transition and perform the following actions:
* Ensure a global BGP configuration exists; if not, initialize one.
* Iterate over all configured VRFs to determine whether a BGP instance exists
* For any insance, update the configuration to use the global system-as
and apply the local-as ASN no-prepend replace-as option on all affected
neighbors to preserve existing behavior.
* If a neighbor is already configured with a local-as directive, that neighbor
will be excluded from the migration process, as it already follows a custom
configuration.
* Add allowas-in per neighbor option. Required to not deny prefix received
updates due to as-path contains our own global ASN.
|
|
isis: T7722: Added interface fast-reroute configuration commands
|
|
listen-address invalid format
|
|
- Added command to disable conntrack per firewall chain
- Added test_disable_conntrack_per_chain function to smoketest
|
|
Requires FRR to support `redistribute table-direct` for ospf
|
|
op-mode: T7745: add a CLI for operator user command permissions
|
|
Added interface fast-reroute configuration commands
|
|
T7743: PPPoE-server add option for VPP control plane
|
|
conntrack: T7482: Fix custom timeouts
|
|
that allows all commands
|
|
Enable PPPoE control-plane integration with VPP, add configurable
option:
- set service pppoe-server interface eth1 vpp-cp
```
interface=eth1,vpp-cp=true
```
|
|
kea: T6211: add VRF support for KEA dhcp server
|
|
|
