In T5835#187967, @dmbaturin wrote:

If you are really that curious, I can attach a screenshot.

If someone wants, I can probably unearth my patches to 1.4 and miniupnpd to make it all work. It was technically functional and worked as expected. I just don't have the time or patience to deal with getting it merged/integrated back into the project.

Out of curiosity, will the details of the poll be public or the results being shared transparently?

In T5835#187963, @dylanneild wrote:

A bunch to unpack here.
[...]

In T5835#187938, @syncer wrote:

Created a poll for maintainers on this topic, and we will go with the decision made.

A bunch to unpack here.

In T5835#187937, @syncer wrote:

go learn how cheap cameras open firewalls via UPnP and make them available on the internet without people being aware of that

or how malware exfiltrates data via port 443 because enterprises can't reliably block outbound traffic on that port.

In T5835#187935, @Viacheslav wrote:

If you know how to test it will be great to test it. If no one needs it even for tests, what are we talking about?

Created a poll for maintainers on this topic, and we will go with the decision made.

In T5835#187936, @simplysoft wrote:

Yes, that is exactly the point. Glad you did not suggest to remove the NAT capability of vyos because it could be used to bypass security or is not appropriate for an "enterprise"

In T5835#187934, @syncer wrote:

In T5835#187933, @simplysoft wrote:

A firewall is doing exactly this all the time when using NAT, autonomously opening ports via call from internal networks (aka internal originated traffic) to allow responses to reach the originator. Enterprises might have some strict outbound rules. For UPnP is exactly the same, an enterprise would have strict rules which services are allowed to open ports.

Not if it's not configured to do so.

In T5835#187933, @simplysoft wrote:

I'm not sure if that summary from you @Viacheslav is fully reflecting the current state.
I'm also not sure if the original implementation never worked, might very well have been broken while refactoring some vyos internals how the firewall is structured, but I guess you should have a better understanding of (the history of) your product. Otherwise I would be very surprised if a broken feature got into your product without every working / being tested.

In T5835#187933, @simplysoft wrote:

A firewall is doing exactly this all the time when using NAT, autonomously opening ports via call from internal networks (aka internal originated traffic) to allow responses to reach the originator. Enterprises might have some strict outbound rules. For UPnP is exactly the same, an enterprise would have strict rules which services are allowed to open ports.

Not if it's not configured to do so.

I'm not sure if that summary from you @Viacheslav is fully reflecting the current state.
I'm also not sure if the original implementation never worked, might very well have been broken while refactoring some vyos internals how the firewall is structured, but I guess you should have a better understanding of (the history of) your product. Otherwise I would be very surprised if a broken feature got into your product without every working / being tested.

I fail to comprehend how a firewall that autonomously opens ports via calls from internal networks is appropriate for an enterprise.
Indeed there are some use cases but this functionality can be used by malicious code and allow bypass security configuration that is enforced otherwise

In summary, it works with custom scripts and patches, but it still does not work from CLI (not fully integrated)
The scripts that should be involved are in the repo https://github.com/miniupnp/miniupnp/tree/miniupnpd_2_3_3/miniupnpd/netfilter_nft/scripts
Until we do not have them and they do not communicate with the firewall, the feature does not work.
A patch is attached in several posts above https://vyos.dev/T5835#174066

In T5835#187919, @syncer wrote:

Does it work now?

Does it work now?

One reasons it is rarely seen is as most are not aware of it being used undercover and when not being present, nothing necessarily brakes (due to fallback to other mechanisms). For some home routers we saw this was an undocumented "feature" that you did not have any control over, more recent & reasonable implementation we have seen allow you to enable or disable it (but nothing much more like fine grained permissions)

I have rarely seen UPnP in enterprise environments and rarely at home even if the main purpose is to use it at home and let applications backdoor your firewall (which often is a bad thing in enterprise evironments).

No doubt that there are other use cases.
since 1.2 LTS, we received zero requests from customers about adding UPnP, hence, don't see any value in it

In T5835#187910, @syncer wrote:

@aidan-gibson main use case is games typically, which is not in priority for us

@aidan-gibson It's never worked, and demand is slim to none
main use case is games typically, which is not in priority for us

bruh

@dmbaturin, I propose removal of upnp stuff from 1.5 and 1.4

Any update on this PR? (thanks for the work put into this!!)

I finally managed to narrow this down further. This problem is caused by enabling the extended nexthop capability. FRR intentionally sends RAs when this capability is enabled, althought so far I don't understand why. I opened a discussion in the FRR repo: https://github.com/FRRouting/frr/discussions/15994

Just so I dont get the vocabulary wrong here...

Ill put it into "known issue" since IMHO a complete "resolved" would be when this feature exists in config-mode aswell.

Feel free to reopen it, but I'm not expecting it to be implemented.

The thing is that adding this as op-mode only doesnt really solve anything.

I think the original request was Add ability to resequence rule numbers for firewall, and we added this tool.
Auto-Apply configuration based on this tool is the wrong way. We haven't had such hacks before and probably won't implement them in the nearest feature.
All configuration changes have to be only per user commit; there should not be any auto-commits/auto applies configs. We have API for these tricks.
CLI is completely different from the cisco/arista logic.

Also NAT-rules are in the need of a resequence feature in the config-mode:

I'm closing this task a solution was included. I'm not in favor of introducing similar command in configuration mode.

Should be fixed after rewriting commit-archive T6304

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

Thanks for the hints, that makes sense. Let's see how that can be implemented :)

For added service when typing just:

You would still be limited to not be able to use " as part of your password.

There should also be migration scripts, as CLI will be changed.

Proposal:

set system config-management commit-archive uri "stor01z-cs.int.trae32566.org/cr01b-vyos"
set system config-management commit-archive scheme "sftp"
set system config-management commit-archive username "cr01b"
set system config-management commit-archive password "$T3$TP@$$W0^%"

We could improve it by breaking up configuration, having the user providing a URI, Protocol and optional username/password as separate values.
Then we can properly encode username/password. This would also give more flexibility how username/password are handled and passed on.

In both cases it is kind of an user error, the password would have to be properly url encoded if provided in one (@ should be %40 in an URI, a ! should be %21).

Running into this issue on VyOS 1.5-rolling-202404280021

set protocols static route xxx.xxx.74.149/32 dhcp-interface eth1.999

@modzilla99 Could you provide an example of set commands to reproduce?

I decided to dig into this a little more and try to trace this out:

sudo nft add chain inet vrf_zones trace_chain { type filter hook prerouting priority -301\; }
sudo nft add rule inet vrf_zones trace_chain meta nftrace set 1

side note, if you flush ruleset, and only add:

Something I just figured out is that the minute I do:

You can create /use your own images

vyos@r4:~$ generate container image foo path 
Possible completions:
  <filename>            Path to Dockerfile

Backport to 1.3 is not worth the trouble since the issue is low-impact.

1.4 is very reasonably clean from that Vyatta cruft, as much as it's possible. We'll create tasks for specific dead code discoveries in the future as needed.

Blowfish support was removed in 1.4, so its key size is no longer an issue.