| Age | Commit message (Collapse) | Author |
|---|
|
Add a loop to check for the dhcp ip address so the commit will not fail if
the interface was configured in the same config session as the vti interface.
|
|
|
|
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
|
|
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>
|
|
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 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
|
|
|
|
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.
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
