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
Mark required input fields with a star as nowadays this is
the de-facto default. Before, it was the other way around and
optional fields were marked.
Signed-off-by: Lars Schumacher <larsen007@web.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Some peers that are behind a NAT router that fails
to properly forward IKE packets on UDP port 500 cannot
establish an IPsec connection. MOBIKE tries to solve that
by sending these packets to UDP port 4500 instead.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Fix bug 10869 as the code has been removed by mistake by the
previous commit dfea4f86c2.
It also includes ipsec.user.conf only when it exists.
Signed-off-by: Lars Schuhmacher <larsen007@web.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
