I'm clearly missing something. I cannot make the configuration as shown by @c-po. If I try to add a 2nd static route, it replaces the first.

The following CLI

cpo@LR1.wue3# show service dhcp-server
 shared-network-name LAN {
     subnet 10.0.0.0/24 {
         default-router 10.0.0.1
         dns-server 194.145.150.1
         lease 88
         range 0 {
             start 10.0.0.100
             stop 10.0.0.200
         }
         static-route 194.145.150.0/24 {
             next-hop 1.1.1.1
         }
         static-route 194.145.151.0/24 {
             router 1.1.1.1
         }
     }
 }

I'm also hitting this issue in 1.4-rolling-202109160217
This task has been kicking around for a while now. What needs to be done to get the code from @ruliane or @elbandi into the rolling build?

Enabling debugging gives me:

Are there updates on this issue?

Related/Duplicate issue of T3680

It's worth adding the no-default-route to the dhcp-options and adding a line like

Thank you for testing!

Something about commands is meddling with strip-private. I'm looking into it.

Now this is quite strange....

$ echo '2001:1578:2fe:fffd::/64' | strip-private
xxxx:xxxx:2fe:fffd::/64

Tested on latest build VyOS 1.4-rolling-202109160217 and confirmed it is adding the remote id attribute by default as expected. Connections establish without issue.

Curl checks come back with:

root@vyos:/tmp# curl 169.254.169.254/latest/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups

xfrm if_id should not be 0

From https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection (1.3 behavior)

Good shout, fixed in following PR: https://github.com/vyos/vyos-1x/pull/1005

This line doesn't match ipv6 addresses https://github.com/vyos/vyos-1x/blob/f86b7314d025fd0cf11c2d91638ed3cc7c4fa507/src/helpers/strip-private.py#L66

Booted my host with 1.4-rolling-202109140217 and confirmed pfs enabled is now generating the expected swanctl.conf file to match the old behavior. If I don't report back in exactly an hour from now that my tunnels died, we can assume the fix works.

Please take a look at the commit 9213ce6672582bc12f02c1530726fe97030d2cfe for kernel 5.13.

To start the proposed CLI:
Needs to be discussed.

1.3-beta-202109120646 doesn't have any commits from T3821:

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

Migration scripts are meant for adjusting old configs for a new configuration syntax version. I feel that using that mechanism for fresh installs is wrong and we should move that logic to a different place, ideally to the script that inserts MAC addresses in the config—I forgot which script it is.

FRR behaviour without "interface" in route - it replaced metric with value without metric

r12-lts(config)# ip route 0.0.0.0/0 192.168.122.1
r12-lts(config)# 
r12-lts(config)# do sho run | include 0.0.0.0
ip route 0.0.0.0/0 192.168.122.1
r12-lts(config)# 
r12-lts(config)# ip route 0.0.0.0/0 192.168.122.1 210
r12-lts(config)# 
r12-lts(config)# do sho run | include 0.0.0.0
ip route 0.0.0.0/0 192.168.122.1 210
r12-lts(config)# 
r12-lts(config)# ip route 0.0.0.0/0 192.168.122.1
r12-lts(config)# 
r12-lts(config)# do sho run | include 0.0.0.0
ip route 0.0.0.0/0 192.168.122.1
r12-lts(config)# 
r12-lts(config)# ip route 0.0.0.0/0 192.168.122.1 eth0 210
r12-lts(config)# 
r12-lts(config)# do sho run | include 0.0.0.0
ip route 0.0.0.0/0 192.168.122.1
ip route 0.0.0.0/0 192.168.122.1 eth0 210
r12-lts(config)#

To reproduce:

set interfaces ethernet eth0 address 'dhcp'
set protocols static route 0.0.0.0/0 next-hop 192.168.122.1

Ot feels thos change broke more then it fixed. Can we revert it?