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

The first three PRs above have been merged, and the next in sequence (https://github.com/vyos/libvyosconfig/pull/21) opened for review.

T6899 merged; when rolling available, kindly retest. Thanks !

This will be squashed with https://vyos.dev/T6326 for backport to Circinus, after confirmation.

This will need the fix in https://vyos.dev/T6899 for backport to Circinus.

Issue present in 1.4.0 tested with Supermicro SOL on ttyS1.

Per slack, this is being investigated for re-introduction into 1.4.1. Putting this on pause for now.

It appears that path-limit GBP network options is deprecated

@Viacheslav @dmbaturin need to be fixed in 1.4.1

Confirmed this is happening with current mainline and 1.4, but not 1.2,1.3 or 1.5.

Needs testing

PR https://github.com/vyos/vyos-1x/pull/4198
Add base64 encrypted password

$ echo -n 1234567890 | base64
MTIzNDU2Nzg5MA==
$ 

Thanks @gadams , and yes that was also mentioned in the forum discussion here:
https://forum.vyos.io/t/vyos-sometimes-does-not-start-properly/15486
I believe the correction made in the PR for the parent task T6899 should help reveal/resolve the issue.

It's not just on upgrade; I'm seeing the same problem in a fresh installation of VyOS 1.5-rolling-202411190007:

Dear Viacheslav,
Glad to hear you.
I think Base64 is ok and is the right approach.

5 endpoints using domain, limit retry to 5 times, total start costs around 5 * 10 = 50 seconds.

@marco_agostani we do not have validators on the insert config step https://github.com/vyos/vyos-1x/blob/8f76c96cb4d7132b7654aa5f37e8ab49fa2e137a/interface-definitions/vpn_ipsec.xml.in#L35-L43
It is more of an interpreter issue/feature

The PR for the parent task:
https://vyos.dev/T6899
will avoid obscuring underlying errors. Revisit after merge of above.

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

Maybe it will be fixed after merging https://vyos.dev/T6045

In T4930#208083, @runar wrote:

Hi @sskaje!

In reference to T1700 and other tickets, there are things in wireguard that is not implemented the "best way".
For the first as noted earlier, the Wireguard kernel module have NO information of the existance of a "DNS peer", DNS to IP mappings are done by the wg config utillity at the moment the command is executed on the device.. this means that entering a DNS name as a peer address will execute a DNS request ONCE and its never retried .

In reference to T1700 and other tickets, there are things in wireguard that is not implemented the "best way".
For the first as noted earlier, the Wireguard kernel module have NO information of the existance of a "DNS peer", DNS to IP mappings are done by the wg config utillity at the moment the command is executed on the device.. this means that entering a DNS name as a peer address will execute a DNS request ONCE and its never retried .

I thought dns look up causes the block. So I made some changes like:

I did some investigation - apparently the plugin cannot match the full command pattern (including optional attributes) and silently refuses to generate a resultant set of commands - I will be looking into this - most likely the issue is related to rm_templates regex patterns for getval

@Viacheslav I made is based on T6490, PR here: https://github.com/vyos/vyos-1x/pull/4194
This PR makes peers no longer required, so WireGuard interfaces will be created on boot, with or without Internet connection, with or without DNS resolution.

Per slack conversation.

@sskaje, what would it be like without an internet connection while the system was loaded? And will the Internet be available 1-2 minutes after boot?
I think you will get the router without wireguard at all, as it was in the previous commits. It cannot resolve the address, so it cannot create a session. And it will be in this state until you reconfigure it again.

Code commit here: https://github.com/sskaje/vyos-1x/tree/T4930

This should be fixed by

@sdwilsh Are you good to close this out? The change in ipv6 should be handled by the updated version now in main

On hold befor the time we rework the op mode system not to use the old Vyatta's code at all

Tried to apply multi_to_list function to ConfigTree().to_json() but it works only for the full config or if pass the path.
The problem is described in the comment on closing the pull request: link. For now there is no way to pass the argument before the filter (json) to the function after the filter

Yes, I linked the article for background why the MTU setting is helpful, this applies to Podman as well as Docker.

We use podman for containers.
Eq command for the podman:

vyos@r14:~$ sudo podman network create pod-net2 --opt mtu=1200
pod-net2
vyos@r14:~$

Check:

vyos@r14:~$ sudo podman network inspect pod-net2
[
     {
          "name": "pod-net2",
          "id": "f1ec367ee95ee0f5b644b7fb96faffa6cf499490e3ff5e8f3915182639302cc7",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2024-11-18T10:08:28.26831792Z",
          "subnets": [
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": true,
          "options": {
               "mtu": "1200"
          },
          "ipam_options": {
               "driver": "host-local"
          }
     }
]
vyos@r14:~$

Since Ipsec secrets al already maintaned in Json config that handle correctly quoting
Is still possible relax the check on the " (double quotes) and let him be saved and commited.
The check is also in commiting phase
I.e.