OpenVPN is an absolute mess. The behaviour of configuration
parameters has been changed over the time; default values have been
changed over time; and it looks like nobody is actually testing
anything any more.
I have been spending hours today on figuring out why OpenVPN
is so damn slow. On a Lightning Wire Labs IPFire Mini Appliance
it achieves about 100 MBit/s in the default configuration when
"openssl speed -evp aes-256-gcm" achieves over 3.5 GBit/s.
Changing any of the cryptography parameters does not change
anything. Throughput remains around 100 MBit/s.
I finally set "cipher none" and "auth none" which disables
encryption and authentication altogether but does not increase
throughput. From here on it was absolutely clear that it was
not a crypto issue.
OpenVPN tries to be smart here and does its own fragmentation.
This is the worst idea I have heard of all day, because that job
is normally done best by the OS.
Various settings which allow the user to "tune" this are grossly
ineffective - let alone it isn't even clear what I am supposed
to configure anywhere. Setting "fragment 1500" weirdly still
does not convince openvpn to generate a packet that is longer
than 1400 bytes. Who'd a thunk?
There is a number of other parameters to set the MTU or which
are related to it (tun-mtu, link-mtu, fragment, mssfix).
On top of all of this we have two "bugs" in ovpnmain.cgi which
are being fixed in this patch:
1) mssfix can be configured by the user. However, we always
enable it in openvpn. The default is on, we only add "mssfix"
which simply turns it on.
It is now being disabled when the user has chosen so in the
web UI. I do not know if this is backwards-compatible.
2) We cap the MTU (tun-mtu) at 1500 bytes when fragment is being
used. So it becomes pointless that the user can this and the
user is not being made aware of this when they hit the save
button.
This was added when we added path MTU discovery. Since that
did not work and was removed, we can remove this now, too.
I archived a solid 500-600 MBit/s of goodput with these settings:
* Disable mssfix
* Set "fragment" to 0
* Set MTU to 9000
I am sure the MTU could be further increased to have bigger packets,
but I did not test how badly this will affect latency of the tunnel.
OpenVPN seems to only be able to handle a certain amount of packets
a second - no matter what. With larger packets, the throughput of
the tunnel increases, but latency might as well.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Cc: Erik Kapfer <erik.kapfer@ipfire.org>
Cc: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
In order to make deanonymisation harder, especially high-risk Tor users
might want to use certain Guard relays only (for example operated by
people they trust), enforce Tor to use Guard relays in certain countries
only (for example countries with very strict data protection laws or
poor diplomatic relations), or avoid Guard relays in certain countries
entirely.
Since Tor sticks to sampled Guards for a long time (usually within the
range of months), restricting those is believed to cause less harm to a
users' anonymity than restricting Exit relays, since their diversity of
a generic Tor user is significantly higher.
This patch extends the Tor CGI for restricting Guard nodes to certain
countries or relays matching certain fingerprints.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This extends the functionality of the Tor CGI in order to be able to
select multiple countries for possible Exit relays, which is - in terms
of anonymity - less worse than limiting all Tor circuits to a single
country.
For example, a user might want to avoid Exit relays in more than one
country, and permit Tor to use Exit relays elesewhere, and vice versa.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The package requires more libraries than libtalloc from
the samba package and therefore we need this dependency
again.
Fixes: #12538
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Added a backup/includes file for apcupsd to backup the
/etc/apcupsd/ directory where all the configuration files
are stored. Currently there is no backup available to
save the state of any changes carried out to the configuration
or action files.
Signed-off-by: Adolf Belka <ahb.ipfire@gmail.com>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This requires that we can load the "microcode" module, but
since the kernel was replaced in this release, we can't load
it any more.
Fixes: #12537
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
libhtp has been updated and suricata 6 requires the new version, so
this lib has to be shipped with the core update.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Fixes: #12529
- If a client N2N configuration will be imported into IPFire systems,
a line will be added which calls the --up script to restart the
static route initscript. Since this is IPFire specific, i will only be
added via import on IPFire system.
- Deleted unneeded line in CLIENTCONF section.
- Added description to SERVERCONF section.
Signed-off-by: ummeegge <erik.kapfer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The second version of this patch only unifies the licence banner, but
leaves GPLv2 untouched. In addition, functions have been changed to use
a script-wide location database handle, as introduced in commit
b62d7e0cc7.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
In order to prevent collateral damage to internal traffic, commit
c69c820025 introduced applying location
block on red0 as a sanity check.
On systems configured to use PPPoE, however, traffic appears on the ppp0
interface instead. This patch checks if a system is configured to use
this connection method, and applies the location filter to this
interface. red0 is used otherwise.
Fixes: #12519
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Full changelog as per https://github.com/speed47/spectre-meltdown-checker/releases/tag/v0.44 :
feat: add support for SRBDS related vulnerabilities
feat: add zstd kernel decompression (#370)
enh: arm: add experimental support for binary arm images
enh: rsb filling: no longer need the 'strings' tool to check for kernel support in live mode
fix: fwdb: remove Intel extract tempdir on exit
fix: has_vmm: ignore kernel threads when looking for a hypervisor (fixes#278)
fix: fwdb: use the commit date as the intel fwdb version
fix: fwdb: update Intel's repository URL
fix: arm64: cve-2017-5753: kernels 4.19+ use a different nospec macro
fix: on CPU parse info under FreeBSD
chore: github: add check run on pull requests
chore: fwdb: update to v165.20201021+i20200616
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When safe search is enabled, it is being enabled on YouTube, too.
This creates problems in some scenarios like schools where politics
is being tought as well as other subjects that might be censored by
YouTube (i.e. election TV spots).
Therefore it is now possible to exclude YouTube from Safe Search
but keep it enabled for the search engines.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
