@ -72,11 +72,6 @@ Configure the frequency of updating the lists of IP addresses that are reserved
Gateway Monitoring
------------------------------------
Kill states
.....................................
When unchecked (enabled) all states will be reset when a gateway is removed (see monitoring in the :doc:`gateways <gateways>` section)
Skip rules
.....................................
@ -135,16 +130,6 @@ Firewall state table optimization to use, influences the number of active states
* [aggressive] Expires idle connections quicker. More efficient use of CPU and memory but can drop legitimate idle connections
* [conservative] Tries to avoid dropping any legitimate idle connections at the expense of increased memory usage and CPU utilization.
Firewall Rules Optimization
.....................................
Influence how the firewall optimizes the generated ruleset.
* [none] Disable the ruleset optimizer.
* [basic] (default) Basic ruleset optimization does four things to improve the performance of ruleset evaluations: remove duplicate rules; remove rules that are a subset of another rule; combine multiple rules into a table when advantageous; re-order the rules to improve evaluation performance
* [profile] Uses the currently loaded ruleset as a feedback profile to tailor the ordering of quick rules to actual network traffic.
Bind states to interface
.....................................
@ -229,7 +214,21 @@ Check certificate of aliases URLs
Make sure the certificate is valid for all HTTPS addresses on aliases. If it's not valid or is revoked, do not download it.
Dynamic state reset
Anti DDOS
------------------------------------
Enable syncookies
.....................................
This option flushes the entire state table on IPv4 address changes in dynamic setups to e.g. allow VoIP servers to re-register.
This option is quite similar to the `syncookies <https://www.freebsd.org/cgi/man.cgi?syncookies>`__ kernel setting,
preventing memory allocation for local services before a proper handshake is made.
In this case pf will be protected agains state table exhaustion.
The following modes are available:
* never (default)
* always
* adaptive - in which case a lower and upper percentage should be specified referring to the usage of the state table.
@ -87,9 +87,39 @@ password When using https authentication, choose a
Make sure to push to a "bare" upstream repository, when pressing "Setup/Test Git" the initial commits should be send to
your git server.
..Tip::
--------------------------
SSH Setup
--------------------------
If you use GitHub, then your only option for git-backup, is to configure it for SSH access since GitHub has removed the ability for external applications to log into your account via your username and password.
The fields in OPNSense under :code:`System / Configuration / Backups / Git` should contain the following:
* URL absolutely MUST follow this format when using GitHub and GitLab: :code:`ssh://github.com/user_name/repo_name.git`. Any URL string that does not follow this pattern will not work.
* Branch should contain the word: :code:`master`
* SSH Private key (discussed below)
* User Name should ONLY contain the word :code:`git`
* password: leave this field empty
You need to create your repository BEFORE enabling git-backup. Do not add any files or READMEs to the repository. In other words, create a BLANK repository.
Next, `create a new SSH key <https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent>`__ specifically for git-backup (only generate the private / public keys per that document and skip the rest). **It is imperative that you do not add a password to your key**, or your backups will fail with authentication errors.
You should set up SSH access to just your repository by assigning your SSH public key to the repository instead of assigning it to your GitHub / GitLab account. Doing this ensures that you don't arbitrarily expose more of your git resources to OPNSense than is absolutely necessary for git-backup to work properly.
If you use GitHub, you can add your SSH public key by going to your repository, then click on :code:`settings`, then :code:`Deploy keys`. Or you can go straight to the URL using this format: :code:`https://github.com/USER_NAME/REPOSITORY_NAME/settings/keys/new`.
* Check the box :code:`Allow write Access`.
For GitHub and GitLab repositories, please make sure your URL follows this structure: :code:`ssh://github.com/user_name/repo_name.git`.
Make sure the fields are populated as stated above and that the Enable box is checked, then click on :code:`Setup / Test Git` and you should see a message come back at the top of the page indicating that the first backup was successful.
@ -102,7 +102,7 @@ Step 5(a) - Assign an interface to WireGuard (recommended)
Finally, it allows separation of the firewall rules of each WireGuard instance (each :code:`wgX` device). Otherwise they all need to be configured on the default WireGuard group that OPNsense creates. This is more an organisational aesthetic, rather than an issue of substance
- Go to :menuselection:`Interfaces --> Assignments`
- In the dropdown next to “New interface:”, select the WireGuard device (:code:`wg0` if this is your first one)
- In the dropdown next to “New interface:”, select the WireGuard device (:code:`wg1` if this is your first one)
- Add a description (eg :code:`HomeWireGuard`)
- Click **+** to add it, then click **Save**
- Then select your new interface under the Interfaces menu
By navigating to :menuselection:`System --> Firmware --> Settings`, you can influence the firmware update settings:
* **Fimware Mirror:** this influences where OPNsense tries to get its updates from. If you have troubles updating or searching for updates, or if your current mirror is running slowly, you can change it here.
* **Firmware Flavour:** OPNsense is available in different flavours. Currently, these flavours influence which cryptographic library to use: OpenSSL (the default) or its drop-in replacement LibreSSL.
* **Release Type:** With this setting, you can switch between the regular fortnightly schedule of tested releases (Production) or the newest, not fully tested code (Development). **Please leave this setting on "Production", unless you fully understand the implications of switching.**
Nick H
1 year ago