Age | Commit message (Collapse) | Author |
|
|
|
|
|
characters.
|
|
Ikev2 reauth option
|
|
Update the VTI creation process to go along with the changes added to
the vyatta-strongswan package, due to changes in the kernel vti module.
This also removes the need for additional netfilter rules to ensure that
packets are directed to the corresponding VTI.
Bug #358 http://bugzilla.vyos.net/show_bug.cgi?id=358
|
|
Move vtiIntf.pm to a more logical place, in line with all the other
packages.
|
|
per-tunnel ikev2-reauth node
|
|
|
|
|
|
Prevent duplicate include statements, for the local rsa keys, being
added to the ipsec.secrets file when more than one VPN connection is
configured.
Bug #332 http://bugzilla.vyos.net/show_bug.cgi?id=332
|
|
Update scripts/vpn-config.pl to have consistent identation levels and
style throughout.
|
|
Rename vti-up-down.sh to vti-up-down to be consistent with others.
|
|
Revert the fix put in place for Bug #183 as this causes multiple routes
to be installed when more than one VTI routes to the same subnet (in
the case of failure over routing etc). As it stands, when one of these
interfaces goes down, the additional route remains active, resulting in
this route still being used even though no traffic can pass.
Removing the up-client fix proposed for Bug #183 fixes this issue and
doesn't affect the normal operation of these VTIs.
Bug #291 http://bugzilla.vyos.net/show_bug.cgi?id=291
|
|
|
|
|
|
Remove automatic IKE version negoiation.
|
|
For IKEv2, there is support for MOBIKE which basically allows IPSec connections to roam from interface to interface. When MOBIKE is used, the IKE negoiation phase uses UDP port 4500 rather than using proto-51.
In strongSwan 4.5.x MOBIKE is automatically enabled for IKEv2 connections. We expose the ability to enable/disable MOBIKE to the user.
|
|
|
|
According to the strongSwan 4.5.x documentation, the keyexchange configuration value "ike" is a synonym to "ikev2".
In strongSwan 5.0.0 however, the configuration value "ike" will try to negoiate IKEv2 connections but will accept IKEv1 connections if the remote peer sends an IKEv1 request.
|
|
|
|
optional "vpn ipsec ike-group <IKEGROUP> key-exchange" parameter.
|
|
Patch by Masakazu Asama.
|
|
Signed-off-by: Daniil Baturin <daniil@baturin.org>
|
|
Signed-off-by: Daniil Baturin <daniil@baturin.org>
|
|
|
|
VYATTA-118: workaround added to update ipsec settings when tunnel local-ip is modified.
|
|
|
|
|
|
|
|
stays the same.
Fix the case when case the <peer,local-address> pairing changes but the tunnel
is still bound to the same vti tunnel interface name(vtiXX).
In that case when doing the cleanup do not delete the vti tunnel of the same
name.
Also fixed 8264: When the vti bind interface name is deleted.
|
|
Vti tunnel uses fwmark from the kernel skbuff. This value is now internally
allocated instead of getting it from the configuration.
Also fixed 8286 where configuration was allowing both a tunnel and VTI between
the same vpn src/dst.
|
|
When a connection-type is respond (configured using: set vpn ipsec
site-to-site peer <ip-addr> connection-type [initiate | respond]), the device
should not keep trying to key forever.
|
|
Fix the error message for undefined intf name in error message.
Also, add changes to incorporate mark's from range 0-2047.
Print warning if a vti interface is defined but not used. Hopefully
this will help users understand that they have a partial configuration.
|
|
interface in show interfaces output though vti configuration exists
The bind, mark parameters can be changed individually but the vti script runs
at the vpn node level. By that time the old value is not known.
With this change now I find out the exisiting vti tunnels from the kernel and
discover the old vti-name, and mark setting from there.
After that it is possible to figure out if
a. No change was done to a VTI: In that case do not do any config.
b. If a tunnel was changed: Delete and create the tunnel again.
c. If a tunnel was deleted: Remove the tunnel config from the kernel.
d. If the tunnel was added: Configure it.
Also, configure the vti interface prior to the strongswan configuration.
This way if the ipsec tunnel comes up then we can bring the interface up/down
(see Bug 8219).
Remove the disable configuration param (see Bug 8221).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
length.
|
|
|
|
interval
|
|
|