Age | Commit message (Collapse) | Author |
|
|
|
It was missed a new line after "mobike" option for
configuration DMVPN
So it generates a wrong config format for swanctl.conf
|
|
|
|
(cherry picked from commit 2d24f456b15dd3a5c53b8119cbc98f45fba3f89e)
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
In case when between hosts exists two IPSec tunnels for VTI (for example, when both sides act as connection initiators), the older unused/replaced tunnel may switch VTI interface to the "down" state even if a newer IPSec connection is still in-use. Depending on other IPSec settings, this leads to a situation when VTI interfaces continuously flapping or stuck in a "down" state.
This fix is an adaptation of PR from @m-asama for the current code base. It adding new dependency from actual SA state of IPSec connection, and do not allow to switch down a VTI interface if at least one of child connections is active or try to change the state of a VTI interface to the same, as already active.
|
|
|
|
* 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
|
|
VTI connections
|
|
|
|
|
|
|
|
|
|
Without this, the outgoing traffic is marked and encrypted but incoming
traffic isn't properly forwarded to the VTI and just gets dropped.
Partially Fixes T137
Signed-off-by: Sylvain Munaut <s.munaut@whatever-company.com>
|
|
|
|
enable config for dead peer detection
|
|
|
|
|
|
|
|
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
|
|
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
|
|
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.
|
|
|
|
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
|