| Age | Commit message (Collapse) | Author |
|---|
|
Remove old comments and other minor tidying up / rearranging of
scripts/vyatta-vti-config.pl
|
|
Perltidy run on scripts/vyatta-vti-config.pl to have consistent
identation levels and style throughout.
|
|
|
|
changes made
to the ipsec config
|
|
Starting with strongSwan 5.3.3, chacha20poly1305 is a supported cipher for
IKE and ESP configurations with an IKEv2 configuration.
|
|
|
|
This may be useful for scenarios where a user prefers to use an ECDSA key
or implement an xauth IPSec RA server without having to code for the VyOS/EdgeOS
platform.
|
|
|
|
|
|
Validate the local address used for VTI based VPN connections to ensure
only either an IPv4 or IPv6 address is used. Currently VTIs can only
accept these for local addresses, other values will fail with
extraneous error messages, trap these earlier in the configuation
commit process for now.
Bug #213 http://bugzilla.vyos.net/show_bug.cgi?id=213
|
|
|
|
Validate the peer address used for VTI based VPN connections to ensure
only either an IPv4 or IPv6 address is used. Currently VTIs can only
accept these for peer addresses, other values will fail with extraneous
error messages, trap these earlier in the configuation commit process
for now.
Bug #359 http://bugzilla.vyos.net/show_bug.cgi?id=359
|
|
|
|
VTI interfaces can remain link down after IPSec SA expiry and renewal,
leaving the actual IPSec tunnel up and active but the route relating to
this VTI interface absent from the routing table; with the end result
of no traffic passing through it without manual intervention. Earlier
fixes for this issue in both bug #183 and bug #291 fixed one issue but
introduced another, this commit fixes both scenarios.
Bug #568 http://bugzilla.vyos.net/show_bug.cgi?id=568
|
|
Remove old comments and other minor tidying up / rearranging of
scripts/vyatta-vti-config.pl
|
|
Perltidy run on scripts/vyatta-vti-config.pl to have consistent
identation levels and style throughout.
|
|
|
|
|
|
|
|
|
|
Update support for RSA keys with strongSwan 5.2.x
|
|
|
|
|
|
|
|
|
|
|
|
strongSwan 5.2.x no longer recognizes keys in RFC 3110 format inlined in
ipsec.conf and ipsec.secrets. We need to convert the local private key
and peer public keys to PEM format, without changing the config templates
or user-visible key formats.
This patch will require the Debian packages 'libcrypt-openssl-bignum-perl'
and 'libcrypt-openssl-rsa-perl' to be added to the system.
|
|
changes made
to the ipsec config
|
|
Since charon's existence, generating them is redundant and as a matter of fact
causes issues with establishing multiple IKEv1 IPSec tunnels to the same peer.
|
|
This might help with strongSwan traversing through firewalls that
filter proto 51, but not UDP traffic.
|
|
|
|
As confirmed by Thermi in the strongSwan IRC channel inside freenode,
this parameter should not have been generated for a S2S VPN setup.
If leftsourceip= is specified on both ends in an IKEv1 S2S VPN tunnel,
both ends will have charon hanging on MODE_CONFIG. This is because both
ends are trying to ask an IP from the remote end which doesn't exist.
|
|
If the user defines main mode, the config script will always enable
aggressive mode. Fix the logic to correctly disable aggressive mode
when main mode is asked for in IKEv1 connections.
|
|
Originally we meant aggressive, not ikev2
|
|
Since we're invoking the logger at runtime, there's really no point
on keeping this codeblock
|
|
Instead of configuring the ipsec logger at config time, configure
it at runtime. The codeblock that generated the logger will be removed
in a subsequent commit
|
|
|
|
strongSwan's charon by design maintains all established connections
regardless, even if the connection's profile has been deleted from
ipsec.conf.
This change will grab a list of old tunnels from the old configuration
and clean up old tunnels that are not present in the new configuration.
|
|
This needs to be updated or VPN configurations won't be properly
handled on subsequent updates.
|
|
Setting this to a default value breaks ikev2 configurations since
aggressive mode is only applicable for ikev1 tunnels
|
|
For some odd reason doing an ipsec update does not make charon
pick up any newly created tunnels. However doing an ipsec reload
updates all newly created tunnels correctly.
|
|
log-modes now expose charon's keywords instead of pluto's keywords.
Refer to the strongSwan's manual to see what each specific logger does.
|
|
|
|
Although strongly not recommended by the developers of strongSwan,
sometimes remote VPN gateways requires this because of interop
reasons or a network admin who doesn't have an idea on why
aggressive mode is bad.
|
|
|
|
In strongSwan 5.0.0 and later series, pfs= and pfsgroup= parameters have
now been removed.
|
|
Since strongSwan 5.0.0, defining the PFS group settings has moved in the
esp= parameter.
If PFS is simply enabled, it will use the first IKE proposal's dh-group as
the PFS group.
|
|
The IKE parameter parser now uses the new get_dh_cipher_result submodule
instead of the old if/else/elseif logic that was hardcoded to the parser.
This should help ease developers adding new Diffie-Hellman groups if there
are any in the future.
|
|
By adding this submodule we can reduce the amount of code we need to
maintain by having a single submodule that takes in a Diffie-Hellman group
number and translates it to what strongSwan expects.
|
|
In preperation of moving towards the strongSwan 5.x series, we are
removing the legacy charonstart=yes parameter in ipsec.conf.
Since strongSwan 5.0.0 pluto has been removed from the codebase and charon
is now the main daemon that handles IKEv1 and IKEv2 connections.
|
