| Age | Commit message (Collapse) | Author |
|---|
|
Re-organize the template code and add addtitional Jinja2 filters for processing
the ifconfig-pool statement. This reverts the changes from commit 7e546be9
("openvpn: T2994: temporary revert to 1.2 crux behavior for client pools").
|
|
Remove workaround which split (local|remote)_address and also subnet keys into
individual keys for the assigned IP address family (4/6).
During template rendering check IP version by introducing new ipv4 and ipv6
Jinja2 filters {% if foo | ipv4 %} or {% if bar | ipv6 %} options.
|
|
|
|
|
|
|
|
A lot of VyOS code requires the Kernel interface to be present in order to
properly work and adjust the interface to the users CLI intends (alias, ipv6,
vrf - just to name a few).
OpenVPN - when run in client mode - only creates the interface (e.g. vtun1) when
the connection to the OpenVPN server was successful. This can't be always the
case due to e.g. software-updates or routing issues to the remote side. This
will in the end result in a zombie OpenVPN client interface where some config
items might not have been set when the interface finally comes up - imagine a
wrong assigned VRF instance.
By always creating the OpenVPN interface manuall we ensure that all the CLI
settings are properly configured in the OS kernel.
|
|
The current implementation for bridge based interfaces has an issue which is
caused by priority inheritance. We always assumed that the bridge interface will
be created last, but this may not be true in all cases, where some interfaces
will be created "on demand" - e.g. OpenVPN or late (VXLAN, GENEVE).
As we already have a bunch of verify steps in place we should not see a bridge
interface leak to the underlaying infrastructure code. This means, whenever an
interface will be member of a bridge, and the bridge does yet not exist, we will
create it in advance in the interface context, as the bridge code will be run
in the same commit but maybe sooner or later.
This will also be the solution for T2924.
|
|
|
|
|
|
|
|
Commit bb9f998 added IPv6 support for OpenVPN, but IPv4 only
configurations stopped working (Address family for hostname not supported)
Commit fc467519 fixed some scenarios by using IPv4 protocols
if 'local-host' is IPv4 address, but the client mode is using
'remote-host' instead and was still broken.
This commit in addition to 'local-host' also checks all the
'remote-host' addresses.
|
|
|
|
airbag must now be explicitly installed.
the patch also allow to fully disables the installation of the logging
code at setup (and not just installing and doing nothing)
|
|
To make SLAAC and DHCPv6 work when forwarding=1, accept_ra must be 2
(default for accept_ra is 1).
|
|
|
|
|
|
- rewrite the function to support both bridge and bonding interface types,
if the type is passed it searches only that type, otherwise it searches
both
- move is_member check out of the deleted condition
- move is_member check to intf_from_dict for interfaces that use it
|
|
|
|
|
|
|
|
|
|
Commit bb9f998 introduced a bug where openvpn fails to start if
'local-host' is an IPv4 address due to 'proto' wanting a IPv6 socket.
This adds a conditional check and uses normal proto if it's IPv4.
|
|
|
|
This reverts commit 26adfd6d0d03af44a03f327478199f3009f2ad3c.
|
|
Unused means disabled or even deleted - there should be no secrets left-over.
|
|
Bug introduced in commit b36e6e6 ("openvpn: T2273: migrate from SysVinit to
systemd") as not all relevant configuration files have been re-rendered
into /run/openvpn
|
|
|
|
- allow configuring IPv6 server addresses and push options
- add IPv6 server client IP pool
- add IPv6 push dhcp-option DNS6
- allow configuring IPv6 server client addresses
- allow configuring IPv6 site-to-site addresses
- validate all IPv6 options and addresses
- use protos that explicitely open an IPv6 listening socket
(tcp6-server, tcp6-client, udp6) as the default on Linux listens on
IPv4 only (https://community.openvpn.net/openvpn/ticket/360)
- add validator for any IPv6 address, host or network (used by pool)
|
|
|
|
2nd part of this fix, first commit 9b6a369 didn't fix it.
|
|
Commit bb36bde introduced a bug when server subnet is unset, this fixes
it.
|
|
openvpn: T2235: add custom server pool handling
|
|
- add config options and logic for server client-ip-pool
- add function for determining default IPs for the server in different
configurations
- verify for pool IPs and maximum subnet prefix length
- move remote netmask logic for client ifconfig-push to use new function
- add topology 'net30' , set it as default (as it already was)
- replace generic ip_* with IPv4* where necessary
- print warning to console when server client IP is in server pool
- fix server subnet help field
|
|
|
|
Commit a457c9d2 moved the config directory to /run/openvpn but didn't move
the client-config-dir in the template.
|
|
convert all call to jinja to use template.render
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- rearranged options to put them in logical groups separated by blank
lines
- removed unnecessary blank lines (whitespace)
- fixed encryption if-else comparison logic that caused 3des to be
ignored
- set tls if tls-version-min is set
|
|
Interfaces enslaved to a bridge are not allowed to be deleted. If an interface
is deleted from the config but it is still enslaved to a bridge will cause a
configuration error on the subsequent boot.
|
|
|
|
|
|
If configured with protocol udp and no local-host, openvpn needs
the 'multihome' option to correctly work on all addresses.
|
|
OpenVPN, WIFI, SSTP all had the same boiler plate copied about checking if a
process associated with a pidfile is running or not. This has been migrated to
the common library function vyos.util.process_running().
|
|
|
