Fixed in https://github.com/vyos/vyos-vm-images/commit/090e5367dc6df9b49c037e0b60f7adfafdf54a53

@fernando Thanks!

i've re-checked with the new image from GCP and new cloud-init version , it seems to be working as expexted :

The kernel is not supporting pseudowire/VPLS now
this patch was never merged into the kernel

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

No, installing the miniupnpd_functions.sh file does not correct the problem.

Another bug it that /config/upnp.leases is hardcoded, but there is no script who creates it https://github.com/vyos/vyos-1x/blob/aebb458262072457c6a3840d1b17031fbd780eca/data/templates/firewall/upnpd.conf.j2#L128

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

Will it work if you manually download the functions? https://github.com/miniupnp/miniupnp/blob/miniupnpd_2_3_1/miniupnpd/netfilter_nft/scripts/miniupnpd_functions.sh

OK, a little digging around in the grub configs led me to a "workaround" solution for the serial console problem after the machine is booted.

Can confirm this is exactly the same in 1.4 rolling (as of Jan 09). Same errors. The miniupnpd daemon receives the request (for either a UPnP, NAT-PMP, or PCP port mapping) and then reports the errors @simplysoft reports in the description.

PR for 1.5 https://github.com/vyos/vyos-1x/pull/2787 which will be backported to 1.4

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

Lowering priority to normal to proceed with adding the interface-monitor daemon development, mentioned above, for 1.5.

Quick test done on a VM with 1 CPU and 1G RAM:

[email protected]# for I in  {1..2542}; do set firewall ipv6 name Test rule $I action accept ; set firewall ipv6 name Test rule $I destination port $I; set firewall ipv6 name Test rule $I protocol tcp ; done
[email protected]# time commit

@sempervictus Thanks for the update!

OK, the grub serial config described here got me as far as seeing the Grub selection screen at boot time.

Oh wow, this is ancient. Can definitely close this out - @zsdc and i figured out a bunch of the insanity around cloud-init since then and i've got it working in our openstacks as well as public clouds on a single config.

What to do with atop and logrorate?

It seems we already have mfa T3834 but it never was documented
https://github.com/vyos/vyos-1x/pull/1008

vyos@r4# set interfaces openvpn vtun0 server mfa totp 
Possible completions:
   challenge            Expect password as result of a challenge response protocol
                        (default: enable)
   digits               Number of digits to use for totp hash (default: 6)
   drift                Time drift in seconds (default: 0)
   slop                 Maximum allowed clock slop in seconds (default: 180)
   step                 Step value for totp in seconds (default: 30)

@xrobau Could you test it?

Dec 9 13:04:57 vyos charon: 07[IKE] no matching CHILD_SA config found

Do you have several connections from the hosts behind the same NAT external address to the same hub?
It worked in my previous tests, but it was just one host behind NAT to connect to the HUB.
Re-check please and close if it works fine now. Need to update.

This is closed now because the required functionality perfectly works with Cloud-init + NoCloud/ConfigDrive.

@amcmillen Do you have any examples of how to deploy it on Linux / Debian, etc?
Without live examples, we'll mark it as wont fix and task will be closed.

As I understand, there are now ways to implement it natively for sshd
Reopen please if you have/know a solution for it.

@ordex Les us know if you have some ideas
Thanks

@fernando @zsdc @joshua Could you re-check it, or can we close it?

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

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

PR for scoped options and bugfixes: https://github.com/vyos/vyos-1x/pull/2785

Is it still bug? @sempervictus could you re-check?
We probably need more details

I guess it is already done https://github.com/vyos/vyos-cloud-init/commit/ae74804ede8fb76a7f27ca869f2b880dbe276ca2
@zsdc Can we close it or you are working on it?

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

PR https://github.com/vyos/vyos-build/pull/484

See also forum thread @ https://forum.vyos.io/t/grub-menu-fails-to-load-on-serial-only-devices-with-no-kvm/

In T5814#171114, @Apachez wrote:

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

I tried manually loading this config in a VM and I'm still not sure what's causing the issue, maybe something isn't waiting properly for bonded interfaces to be created?:

vyos@vyos# load config.boot-cr01a-vyos.20240109_232428
Loading configuration from 'config.boot-cr01a-vyos.20240109_232428'
Load complete. Use 'commit' to make changes effective.
[edit]
vyos@vyos# commit

In T3871#160827, @jestabro wrote:

@stingalleman As mentioned above (and confirmed in discussions earlier this week), we've had few if any reports of issues with the udev approach, so we would be very interested to hear details of your case.

@himurae, Permission and ownership of config directory and files and fine. If you are still seeing the DHCP leases not being created, something else is probably going on.

Put in the PR for this at https://github.com/vyos/vyos-1x/pull/2780

Could for example be that set system options logtoram enables the feature while set system options logtoram size 32M sets the desired size where the default is 32M or whatever would be needed as a sane minimum.

Maybe making the size of the ramdisk configurable via CLI would be wise? I feel that there's enough variation in hardware configurations out there that hard-coding a value would cause problems.

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

As a side comment, the new firewall system allows more granular control and sometimes may simplify configuration. It follows better the lower level logic of nftables.

Yes, I agree with that, readability will be better if everything is in order.

I suggest changing order just as a cosmetic fix: feels more reasonable/readable to parse first "incoming", and then "outgoing"

@n.fort
Looks like 1) and 2) is correct, as well as 'Action=accept in vyos command shall remain as accept in nftables'.
However, the 3) is not obvious to me. As long as all rules with Action=Accept in both IN and OUT chains will migrate to Action=return, looks like there should be no difference in order, other than probably for performance reason.

I stopped using conntrack-sync before I moved to 1.3 (which I am currently running) so I can't confirm either way.
I expect it's no longer an issue though and this task can be closed.

Should be a non-issue with the new firewall implementation.

Changes that seems to be needed only in migration script https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/firewall/10-to-11:

• Use accept action for base-chains (it's done, no change needed here).
• Migrate action=accept to action=return on every rule.
• fix order and ensure all "in" rules are applied first.