e9edb11535
* VPN: OpenVPN: Instances - add new module using the same approach as introduced for IPsec in 23.1. Since we likely can't easily migrate the old cruft, we better focus on offering the correct options for openvpn following upstream documentation. o add boilerplate o implement a solution to keep vpnid's unique so device creation for legacy and mvc can function in similar ways. o add some of the main "helper" options for clients and servers o Implement certificate logic, selecting a certificate also implies an authority (which we validate) o hook CRL generation into the exising openvpn_refresh_crls() event o attach already refactored authentication to new MVC as well, OpenVPN->getInstanceById() is responsible for feeding the data needed during authentication and overwrite generation. o when in client mode and in need for a username+password combination, flush these to file and link in "auth-user-pass" o routes (remote) and push routes (local), combine IPv4 and IPv6 for ease of administration, o keep alive [push] ping-[restart] defined as seperate fields for validation o add various "push" to client options in Miscellaneous section o add "auth-gen-token" lifetime for https://github.com/opnsense/core/issues/6135 o allow selection of redirect-gateway type for https://github.com/opnsense/core/issues/6220 o move tls-auth/crypt into separate static keys objects (tab in instances page) o hook existing events (ovpn_event.py) and make sure they locate the server using getServerById() when needed o use getInstanceById in openvpn_prepare() to return both legacy as MVC device configuration o add ovpn_service_control.php for service control [stop|start|restart|configure] and glue this in openvpn_services() via configd o change openvpn_interfaces() to use isEnabled() method on the model to query if any (legacy/mvc) instances are enabled o move openvpn_config() from openvpn.inc to widget and extend with MVC instances o extend ovpn_status.py to parse "instance-" sockets as well, since the filename doesn't explain the role, we're using the status call to figure out the use. uuid's are keys in this case o server_id type to str in kill_session.py so we can match either legacy or mvc sockets o hook ExportController to OpenVPN model using getInstanceById() to glue the Client Export utility to both components o extend connection status with mvc sessions (descriptions) --------- Co-authored-by: Franco Fichtner <franco@opnsense.org>
OPNsense GUI and system management
The OPNsense project invites developers to start contributing to the code base. For your own purposes or – even better – to join us in creating the best open source firewall available.
The build process has been designed to make it easy for anyone to build and write code. The main outline of the new codebase is available at:
https://docs.opnsense.org/development/architecture.html
Our aim is to gradually evolve to a new codebase instead of using a big bang approach into something new.
Build tools
To create working software like OPNsense you need the sources and the tools to build it. The build tools for OPNsense are freely available.
Notes on how to build OPNsense can be found in the tools repository:
https://github.com/opnsense/tools
Contribute
You can contribute to the project in many ways, e.g. testing functionality, sending in bug reports or creating pull requests directly via GitHub. Any help is always very welcome!
License
OPNsense is and will always be available under the 2-Clause BSD license:
https://opensource.org/licenses/BSD-2-Clause
Every contribution made to the project must be licensed under the same conditions in order to keep OPNsense truly free and accessible for everybody.
Makefile targets
The repository offers a couple of targets that either tie into tools.git build processes or are aimed at fast development.
make package
A package of the current state of the repository can be created using this target. It may require several packages to be installed. The target will try to assist in case of failure, e.g. when a missing file needs to be fetched from an external location.
Several OPTIONS exist to customise the package, e.g.:
- CORE_DEPENDS: a list of required dependencies for the package
- CORE_DEPENDS_ARCH: a list of special -required packages
- CORE_ORIGIN: sets a FreeBSD compatible package/ports origin
- CORE_COMMENT: a short description of the package
- CORE_MAINTAINER: email of the package maintainer
- CORE_WWW: web url of the package
- CORE_NAME: sets a package name
Options are passed in the following form:
# make package CORE_NAME=my_new_name
In general, options are either set to sane defaults or automatically detected at runtime.
make update
Update will pull the latest commits from the current branch from the upstream repository.
make upgrade
Upgrade will run the package build and replace the currently installed package in the system.
make collect
Fetch changes from the running system for all known files.
make lint
Run several syntax checks on the repository. This is recommended before issuing a pull request on GitHub.
make style
Run the PSR2 and PEP8 style checks on MVC PHP code and Python, respectively.
make sweep
Run Linux Kernel cleanfile whitespace sanitiser on all files.