Page MenuHomeVyOS Platform

Selectors for route-based IPsec tunnel (vti)
Open, Requires assessmentPublicFEATURE REQUEST

Description

Hi,

Could you add support for specifying selectors for route-based IPsec tunnels that use VTI interfaces? At the moment it is not possible and VyOS always uses 0.0.0.0/0 <-> 0.0.0.0/0.
https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-traffic-selectors-in-route-based-vpns.html

We have multiple connections including VPN tunnels to many 3rd parties. Most of them require the selectors to be non 0.0.0.0/0. As we use zone-based policies to make traffic management easier therefore we have to use VTI for IPsec to be able to add it to a zone.

This should be easy to do as strongswan/libreswan already supports it. I've edited the ipsec.conf file manually and it works.

conn peer-x.x.x.x-tunnel-vti-1
        left=y.y.y.y
        right=x.x.x.x
        rightsubnet=192.168.100.0/24
        leftsubnet=10.0.252.112/29
        ike=aes256-sha256-modp1024!
        keyexchange=ikev1
        aggressive=no
        ikelifetime=86400s
        closeaction=none
        esp=aes256-sha256!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437185
        leftupdown="/usr/lib/ipsec/vti-up-down vti1"
        auto=start
        keyingtries=%forever
#conn peer-x.x.x.x-tunnel-vti-1

conn peer-x.x.x.x-tunnel-vti-2
        left=y.y.y.y
        right=x.x.x.x
        rightsubnet=192.168.101.0/24
        leftsubnet=10.0.252.112/29
        ike=aes256-sha256-modp1024!
        keyexchange=ikev1
        aggressive=no
        ikelifetime=86400s
        closeaction=none
        esp=aes256-sha256!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437185
        leftupdown="/usr/lib/ipsec/vti-up-down vti1"
        auto=start
        keyingtries=%forever
#conn peer-x.x.x.x-tunnel-vti-2
$ show vpn ike sa 
Peer ID / IP                            Local ID / IP               
------------                            -------------
x.x.x.x                           y.y.y.y                         

    State  IKEVer  Encrypt  Hash    D-H Group      NAT-T  A-Time  L-Time
    -----  ------  -------  ----    ---------      -----  ------  ------
    up     IKEv1   aes256   sha256_128 2(MODP_1024)   no     18000   86400 
 
$ show vpn ipsec sa 
Connection                       State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
-------------------------------  -------  --------  --------------  ----------------  ----------------  -----------  -----------------------------
peer-x.x.x.x-tunnel-vti-1  up       4h33m35s  40K/336B        496/4             x.x.x.x     N/A          AES_CBC_256/HMAC_SHA2_256_128
peer-x.x.x.x-tunnel-vti-2  up       4h33m35s  252B/252B       3/3               x.x.x.x     N/A          AES_CBC_256/HMAC_SHA2_256_128

Thanks,
Damian

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Related Objects

StatusSubtypeAssignedTask
Needs testingsdev
OpenFEATURE REQUESTNone

Event Timeline

krox2 updated the task description. (Show Details)

@krox2 How should looks like a configuration for many local/remote traffic selectors per one vti interface?

@Viacheslav Can be similar to policy-based ipsec

# set vpn ipsec site-to-site peer 1.1.1.1 tunnel 1 
Possible completions:
   allow-nat-networks
                Option to allow NAT networks
   allow-public-networks
                Option to allow public networks
   disable      Option to disable vpn tunnel
   esp-group    ESP group name
 > local        Local parameters for interesting traffic
   protocol     Protocol to encrypt
 > remote       Remote parameters for interesting traffic

For example:

set vpn ipsec site-to-site peer [peer IP] vti bind [vti interface]
set vpn ipsec site-to-site peer [peer IP] vti tunnel [<0-4294967295>]
Possible completions:
   allow-nat-networks
                Option to allow NAT networks
   allow-public-networks
                Option to allow public networks
   disable      Option to disable vpn tunnel
   esp-group    ESP group name
 > local        Local parameters for interesting traffic
   protocol     Protocol to encrypt
 > remote       Remote parameters for interesting traffic

Apologies if it is not what you're question was about.

I've also noticed that vti interface wasn't brought up when the tunnel came up. I had to bring it up manually. I will raise another ticket if this still will be the case.

PR: https://github.com/vyos/vyos-1x/pull/872

The PR allows it to be set like:

set vpn ipsec site-to-site peer [IP] vti local prefix 10.1.1.0/24
set vpn ipsec site-to-site peer [IP] vti remote prefix 10.2.2.0/24
set vpn ipsec site-to-site peer [IP] vti remote prefix 10.3.3.0/24

@sdev Will it not create a full mesh, for example:
10.10.10.0/24 <--> 192.168.10.0/24
10.10.20.0/24 <--> 192.168.20.0/24
It will also set IPsec for 10.10.10.0/24 <--> 192.168.20.0/24 and 10.10.20.0/24 <--> 192.168.10.0/24 that may not be desired.

@krox2 Oh I think I understand what you mean. You'd want to also be able to create multiple child SAs each with unique left/right subnets?

@sdev Yes, this can be done identically as the tunnel definition.

I wonder if instead it should just use the existing tunnel node for this. So if VTI is set on a peer, all configured tunnels get marked for the VTI interface. Current VyOS behaviour allows only for tunnels, or VTI - not both.

Example config:

...
set vpn ipsec site-to-site peer 192.51.100.2 vti bind vti10
set vpn ipsec site-to-site peer 192.51.100.2 vti esp-group 'esp'
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 0 esp-group 'esp'
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 0 local prefix 10.1.1.0/24
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 0 remote prefix 10.2.2.0/24
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 0 remote prefix 10.3.3.0/24
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 1 esp-group 'esp'
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 1 local prefix 10.1.1.0/24
set vpn ipsec site-to-site peer 192.51.100.2 tunnel 1 remote prefix 10.4.4.0/24

Output:

conn peer-192.51.100.2-tunnel-0
    ...
    leftsubnet = 10.1.1.0/24[%any/%any]
    rightsubnet = 10.2.2.0/24[%any/%any],10.3.3.0/24[%any/%any]
    ...
    leftupdown = "/etc/ipsec.d/vti-up-down vti10 no"
    mark = 9437194

conn peer-192.51.100.2-tunnel-1
    ...
    leftsubnet = 10.1.1.0/24[%any/%any]
    rightsubnet = 10.4.4.0/24[%any/%any]
    ...
    leftupdown = "/etc/ipsec.d/vti-up-down vti10 no"
    mark = 9437194

Edit: Updated my PR with the above setup.

@sdev That makes sense, you can also get rid of "esp-group" under vti as it will be specified per tunnel.
I like that we can specify multiple prefixes under one tunnel but also can configure multiple tunnels for more complex scenarios.

I've left vti esp-group to keep backwards compatibility with current behaviour when vti is configured without any tunnels (when it uses 0.0.0.0/0), in that scenario it would still use the group specified.

It's a bit confusing, I can create a tunnel with 0.0.0.0/0 if I need it. That how it is also done on PaloAlto FW and Fortigate. Anyway, it is just my opinion. Thanks for picking up this request so quickly.