| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
level
Getting rid of "set firewall options" and move it from:
set firewall options interface ethX adjust-mss 1400
set firewall options interface ethX adjust-mss6 1400
to:
set interfaces ethernet ethX ip adjust-mss 1400
set interfaces ethernet ethX ipv6 adjust-mss 1400
In addition add an extra option called clamp-mss-to-pmtu instead of a value.
|
|
|
|
|
|
This reverts commit 29e438755c8bd2b9598a2016a3c42891f0cbfa1d.
|
|
|
|
commit_in_progress()
|
|
Inspired by the comments of https://unix.stackexchange.com/a/435317 use a more
robust approach. A service can be "active" but not "running" (e.g. restarting
with a configuration error). We can now test if a systemd unit is "activated"
and if it is "running" at all.
>>> from vyos.util import is_systemd_service_active
>>> from vyos.util import is_systemd_service_running
>>> is_systemd_service_active('ssh')
True
>>> is_systemd_service_running('sshd')
False
>>> is_systemd_service_running('ssh')
True
|
|
|
|
VyOS will automatically append the subsystem name (pppoe-server or sstp) when
something goes wrong. No need to hardcode this into the error string a second
time.
|
|
|
|
|
|
This reverts commit a2b959c50c96698da173b9c4720369a51442cc5c.
|
|
|
|
|
|
|
|
|
|
|
|
The class ConfigTreeActiveQuery uses configtree to access tag node
values; note that this will only report saved configuration data.
|
|
In some cases, we need to wait until local address is assigned.
And only then l2tpv3 tunnel can be configured.
For example when ipv6 address is in "tentative" state
or we wait for some routing daemon/route for a remote address.
|
|
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.
|
|
Test is a specified systemd service is actually running.
Returns True if service is running, false otherwise.
|
|
|
|
generate ipsec mac-ios-profile <connection> remote <ip|fqdn>
will generate a matching IPSec profile which can be loaded on an iOS device.
|
|
|
|
Also renames peer pubkey to public-key for consistency
|
|
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
|
|
|
|
|
|
|
|
When waiting for processes that don't take long,
we need add an inotify watcher _before_ starting that process.
The pre-hook arguments allows the user to pass a () -> () anonymous function
to be called before adding a watch.
|
|
|
|
Also adds check for the charon socket instead of an arbitrary sleep()
|
|
vyos.util method `dict_search_args` to allow for dot characters in keys.
|
|
|
|
pki: T3642: Add standard extensions to generated certificates
|
|
|
|
Keep the vyos.util function clean and not pull in the rest of the world
when importing it.
|
|
|
|
|
|
Remove python3-crypto dependency.
|
|
The IPSec ceritifcate handling is now done by storing the CA key inside the
running configuration.
|
|
* 'pki_ipsec' of https://github.com/sarthurdev/vyos-1x:
pki: ipsec: T3642: Update migration script to account for file permission issues
pki: ipsec: T3642: Migrate IPSec to use PKI configuration
pki: T3642: New PKI config and management
|
|
Commit 5303ec39 ("vyos.util: add new helper copy_file()") added a new helper
function to copy a file from A -> B and create the destination directory if
required. It did also throw an excpetion if the destination file already
existed and consisted of the same file - this is now ignored and we always
copy the source to the destination.
|
|
|
|
XFRM interfaces are similar to VTI devices in their basic functionality but
offer several advantages:
* No tunnel endpoint addresses have to be configured on the interfaces.
Compared to VTIs, which are layer 3 tunnel devices with mandatory endpoints,
this resolves issues with wildcard addresses (only one VTI with wildcard
endpoints is supported), avoids a 1:1 mapping between SAs and interfaces, and
easily allows SAs with multiple peers to share the same interface.
* Because there are no endpoint addresses, IPv4 and IPv6 SAs are supported on
the same interface (VTI devices only support one address family).
* IPsec modes other than tunnel are supported (VTI devices only support
tunnel mode).
* No awkward configuration via GRE keys and XFRM marks. Instead, a new identifier
(XFRM interface ID) links policies and SAs with XFRM interfaces.
|
|
Add implementation with XML and Python.
|
|
Copy a file from A -> B but also support adjusting Bs file permissions
and creation of Bs base directory if required.
|
