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?

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

1.5 PR: 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.

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.

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.

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.

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.

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

I presume it's no longer an issue, but I'd like to confirm.

The original syntax is now allowed anymore.

Should be easy to do now that ipaddrcheck supports range validation.