Hi Lorenzo, I agree vti is very limiting! I am glad to hear about xfrmi. I saw two tunnels between gateways send traffic using VTI. So I am curious what is different in your case. Or are you dealing with something else?
Here are a couple of outputs from libreswan testing this is the verbose output. https://swantest.libreswan.fi/results/blackswan/2018-01-05-swantest-3.22-596-g6bac0de35-master/netkey-vti-09/OUTPUT/west.console.verbose.txt [root@west netkey-vti-09]# ip xfrm state src 192.1.2.23 dst 192.1.2.45 proto esp spi 0x0eb97a56 reqid 16393 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0xcf25becdc6c196ff04b9e893d2caa387ed63bc96cf66ab7c1e5c74d32b9eeb801f06fbf3 128 src 192.1.2.45 dst 192.1.2.23 proto esp spi 0x507929e8 reqid 16393 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0x8b5f8143cb6f361e57b0096bc1a444a65e244f97ba76e8779b968bcae54b78cea7c17d38 128 src 192.1.2.23 dst 192.1.2.45 proto esp spi 0x73eab5cf reqid 16389 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0xb00cc4d0da414cba35c9a41e176fdafb92af0a7912d633c1c3f4623bee2d090173e3fca3 128 src 192.1.2.45 dst 192.1.2.23 proto esp spi 0x52581beb reqid 16389 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0x01b906499806ec2436ffe125f54ce297c3a3a14bb19fcbf51f16888c6927a20cd0dc5e67 128 a santized output https://swantest.libreswan.fi/results/blackswan/2018-01-05-swantest-3.22-596-g6bac0de35-master/netkey-vti-09/OUTPUT/west.console.txt Also from an older test: https://swantest.libreswan.fi/results/blackswan/2018-01-04-swantest-3.22-596-g6bac0de35-master/netkey-vti-02/OUTPUT/west.console.txt regards, -antony On Thu, Dec 21, 2017 at 02:06:00AM +0900, Lorenzo Colitti wrote: > When using IPsec tunnel mode, VTIs provide many benefits compared > to direct configuration of xfrm policies / states. However, one > limitation is that there can only be one VTI between a given pair > of IP addresses. This does not allow configuring multiple IPsec > tunnels to the same security gateway. This is required by some > deployments, for example I-WLAN [3GPP TS 24.327]. > > This patchset introduces a new VTI_KEYED flag that allows > configuration of multiple VTIs between the same IP address > pairs. The semantics are as follows: > > - The output path is the same as current VTI behaviour, where a > routing lookup selects a VTI interface, and the VTI's okey > specifies the mark to use in the XFRM lookup. > - The input and ICMP error paths instead work by first looking up > an SA with a loose match that ignores the mark. That mark is > then used to find the tunnel by ikey (for input packets) or > okey (for ICMP errors). > > In order for ICMP errors to work, flags are added to the common > IP lookup functions to ignore the tunnel ikey and to look up > tunnels by okey instead of ikey. > > On the same IP address pair, keyed VTIs can coexist with each > other (as long as the ikeys are different), but cannot coexist > with keyless VTIs. This is because the existing keyless VTI > behaviour (which this series does not change) is to always accept > packets matching an input policy, regardless of whether there is > any matching XFRM state. Thus, the keyless VTI would accept the > traffic for the keyed tunnel and drop it because it would not > match the keyed tunnel's state. > > Changes from RFC series: > - Processing of ICMP errors now works when ikey != okey. > - Series now contains changes to the common tunnel lookup > functions to match tunnels by okey and to ignore ikey when > matching. > - Fixed missing EXPORT_SYMBOL for xfrm_state_lookup_loose. > - Made vti6_lookup static as it should have been.
