File uploads did not work since Perl was upgraded. This patch
fixes that problem by only checking if an object was returned
instead of performing a string comparison.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This is supported since strongswan 5.7.2 and is a good alternative
to Curve25519 because Curve448 is almost equally secure but performs
faster.
https://en.wikipedia.org/wiki/Curve448
This is enabled by default although we do not expect many other
implementations to be able to support this.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
The changes introduced due to #12091 caused IPsec ESP
to be invalid if PFS ciphers were selected. Code has
to read "!$pfs" instead of just "$pfs", as it should trigger
for ciphers _without_ Perfect Forward Secrecy.
Fixes#12099
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This field is required and therefore we need to initialize it
for old connections. Right now, the CGI throws an error message
when editing an existing connection without the MTU being filled
in.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Fixes#11904
Since OpenSSL-1.1.0x the database attribute file for IPSec and OpenVPN wasn´t created while initial PKI generation.
OpenVPN delivered an error message but IPSec did crashed within the first attempt.
This problem persists also after X509 deletion and new generation.
index.txt.attr will now be delivered by the system but also deleted and recreated while setting up a new x509.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The algorithm is selected by default since it is considered
to be both secure and state-of-the-art. This required Linux kernel
> 4.2, which is satisfied by Core Update 2.12 122.
Fixes#11549
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This allows to create an IPsec connection that will never actively
try to reach the other peer. It helps in environments where this is
not desired or impossible because of NAT.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When a tunnel that is in always-on configuration closes
unexpectedly, we can instruct strongSwan to restart it
immediately which is precisely what we do now.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
These are not considered secure anymore but are unfortunately
still needed in some cases (legacy hardware, ...).
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The compression is causing some interoperatibility issues
and does not really compress data very much - even when the
data is quite compressible.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is helpful when debugging on-demand connections
when you can see if strongswan tries to connect or is
still idle.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Since we somehow have to support these algorithms this patch
adds some information for the user that it is very strongly
discouraged to use them in production.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
MODP-768 is broken but some systems out there (for example old
Cisco ASAs) do not support anything better. Hence it is better
to allow this instead of using no VPN at all.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
IPsec is still proposing to use SHA1 and MODP-1536 or MODP-1024
when initiating a connection. These are considered weak although
many off-the-shelf hardware is still using this as defaults.
This patch disables those algorithms and additionally changes
default behaviour to only accept the configured cipher suites.
This might create some interoperability issues, but increases
security of IPFire-to-IPFire IPsec connections.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This will create IPsec VPN connections with auto=route set
instead of auto=start which will cause the connection being
created, but not brought up yet.
As soon as the first packet is received, the connection will
be established and data will be passed through it.
This allows IPFire to handle more VPN connections on weaker
systems and avoids negotiating many connections which are
rarely used.
Suggested-by: Tom Rymes <tomvend@rymes.com>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Fixes: #10733
