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.

vyos-vm-images will soon be phased out completely.

This issue is on and off, but mostly solved now.

This needs to be properly worded as a feature request, if it's still relevant with the new firewall implementation.

No longer reproducible in 1.5

The CLI prevents that now.

Someone needs to test it on a system with a real wireless NIC.