The question is if this is really relevant - as to my knowledge it is not possible to clear those counters unless unloading and reloading the interface driver(s)

Works with implementation of T3620

Included in PR: https://github.com/vyos/vyos-1x/pull/881

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.

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.

@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 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.

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

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

@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?

This does not appear to be fixed; I think it's something specific to 1.4:

trae@cr01a-vyos# commit
Using source address fd52:d62e:8011:fffe:192:168:253:2
Archiving config...
  sftp://stor01z-rh8.int.trae32566.org:/int/cr01a-vyos Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 287, in upload
    upload_sftp(local_path, url.hostname, url.path, username, password, port, source, progressbar)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 166, in upload_sftp
    transfer_sftp('upload', *args, **kwargs)
  File "/usr/lib/python3/dist-packages/vyos/remote.py", line 162, in transfer_sftp
    sock.shutdown()
TypeError: shutdown() takes exactly one argument (0 given)
[edit policy route-map BGP-BACKBONE-OUT]
trae@cr01a-vyos# run show ver

I have a similar problem, but different, in T3563. I've reopened it and added information, but basically 1.4 still has the issue reported in that bug report.

See [1] from the previous post:

Note: If you don't want to install anything and don't care about some potential security problems, just enable the following 2 options to get native GRE keepalive support on Linux: […]

I care. Setting these sysctl parameters allows for relaying arbitrary traffic through the router.

@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.

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

@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

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