Age | Commit message (Collapse) | Author |
|
Added the possibility to configure Pseudo-Random Functions (PRF) in IKE group
set vpn ipsec ike-group <Ike-grp> proposal <number> prf <PRF>
Backport from 1.4
|
|
IPsec: T4087: increasing the maximum number of IKE proposals
|
|
LogLevel confiugration modes for ipsec are applied without any
check the state of the 'charon' process i.e at this time it tries
to apply config to not fully loaded charon process
Add checks and timeout for charon process, before executing IPSec
logging options and logging modes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The protocol selector used for tunnels in transport mode was ignored by the configuration script.
This commit adding it as a part of left|rightsubnet, as required by strongSwan.
|
|
When in ESP group configured "pfs enable" option (default behavior), PFS settings are taken from the IKE proposal 1. In case if there is no "proposal 1", this ends up with broken ESP settings and unusable VPN peer.
This fix replacing logic by taking PFS from the first one IKE proposal, regardless of its number.
|
|
|
|
The list of supported cipher suites actualized according to the:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
|
|
|
|
* make dhcp interface work for vti interfaces
* clean up code, loger timeout use python api
* change vti tunnel ip on new dhcp lease
* only change ip on up and do not get non dhcp ip
* fix error in function, include up-host and down-host
|
|
|
|
Two IPsec kernel stacks are currently available: KLIPS and NETKEY. The
Linux kernel NETKEY code is a rewrite from scratch of the KAME IPsec
code. The KAME Project was a group effort of six companies in Japan to
provide a free IPv6 and IPsec (for both IPv4 and IPv6) protocol stack
implementation for variants of the BSD UNIX computer operating system.
KLIPS is not a part of the Linux kernel. When using KLIPS, you must
apply a patch to the kernel to support NAT-T. When using NETKEY, NAT-T
support is already inside the kernel, and there is no need to patch the
kernel. [1]
KLIPS part has been removed as we always used the NETKEY path in the
Perl script.
[1]: https://www.linuxjournal.com/article/9916
|
|
'interfaces' option no longer available in StrongSWAN as of their Wiki [1].
[1]: https://wiki.strongswan.org/projects/strongswan/wiki/ConfigSetupSection
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/TriJetScud/vyatta-cfg-vpn into current
|
|
depricated."
This reverts commit fbddff7f2b6b485c93b5d3cf4d60a75f84c3a2b6.
|
|
This reverts commit 8353f0f8fc746c69d6006e5bba9baf45afe16385.
|
|
|
|
|
|
|
|
|
|
Conflicts:
templates/vpn/ipsec/esp-group/node.tag/proposal/node.tag/encryption/node.def
templates/vpn/ipsec/ike-group/node.tag/proposal/node.tag/encryption/node.def
Get the GCM and ChaCha20+Poly1305 ciphers to play nice with each other
|
|
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
|
|
|
|
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 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
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|