I'm still seeing this in VyOS 1.3-rolling-202004170117

We took other steps that allows us to take the image back to a manageable size, and this task lost its immediate relevance.

This is confusing. While NTP used to work (listen on all interfaces) without any listen-address set, now it doesn't. This means any old config without listen-address set will now have a non-working NTP without any warning. There was no migration script to migrate the old behavior to the new. ntp should have a mandatory listen-address if this new behavior is kept.

Do you know what the outcome of this old task was?

While "interface ignore wildcard" configured, we got:

ntpq -c lpeer
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.255.0.1      .INIT.          16 u    -   64    0    0.000    0.000   0.000

You are absolutely right. Was a stressful morning sorting this out, thanks for the response.

@LBegnaud if I read the source correct the command set vpn ipsec options disable-route-autoinstall is what you are looking for, it was implemented in T71.

Yes definitely just ran into this myself. I think i had the opposite problem of OP. I have only ipsec VTI on the router, but whenever a reset vpn ipsec-peer command was run, the peer IP was being added as default route for table 220. Furthermore, this was being respected as the default route for the system (I'm not sure how route priority works with tables, but i'm guessing table 220 has preference over table main?)

@dmbaturin ok, will address that in the next rewrite

@alkersan Looks good, thanks!

A pair of PRs were made in vyos-1x and vyatta-op.
Thought they would get linked to this task by phabricator automatically, but that didn't happen.

@dmbaturin is there any reason the IPv6 peer-group is under address-family ipv6-unicast and the IPv4 peer-group is not? Seems this one was missed during migration?

@syncer @dmbaturin - I'm experiencing this on upgrade from 1.1.8 to 1.2.1, is this expected behaviour that you have to chown it?

Need to reopen this task.
Version: 1.2.0-LTS.
Running configuration:

vyos@test-01# show 
 interfaces {
     ethernet eth0 {
         address 192.168.55.18/30
         duplex auto
         hw-id 08:00:27:95:bb:f6
         smp-affinity auto
         speed auto
     }
     ethernet eth1 {
         address 192.168.56.3/24
         duplex auto
         hw-id 08:00:27:8e:d6:fb
         smp-affinity auto
         speed auto
     }
     ethernet eth2 {
         duplex auto
         hw-id 08:00:27:8c:27:04
         smp-affinity auto
         speed auto
     }
     loopback lo {
     }
 }
 service {
     ssh {
     }
 }
 system {
     config-management {
         commit-revisions 100
     }
     console {
         device ttyS0 {
             speed 9600
         }
     }
     host-name test-01
     login {
         user vyos {
             authentication {
                 encrypted-password $6$7X4XbQJ2xVMZ8$NmISPmyC1f88cIfcKig01pkjePNTVeeWwULrHgich6wB0A1TH/b31Jywpsde8Mv4/B8Qa5CxFM.rlXmfOQT0Z0
                 plaintext-password ""
             }
             level admin
         }
     }
     name-server 1.1.1.1
     ntp {
         server 0.pool.ntp.org {
         }
         server 1.pool.ntp.org {
         }
         server 2.pool.ntp.org {
         }
     }
     syslog {
         global {
             facility all {
                 level info
             }
             facility protocols {
                 level debug
             }
         }
     }
     time-zone UTC
 }

No issue known but it eases reproducibility