Unlikely but, possible MD5 hash collision?

There are genuine use cases, especially for small/home networks. But UPnP is a literal minefield of problems, and on top of that has had some serious security issues in the past due to fundamental design. If you were going to do this, I would want it off by default.

I think the intention here is by default build with no liveCD support, and use the flag to explicitly build liveCD images when needed. The justification is if an image is cloud type image, there are certain security assumptions about the live network the image is connected to (because many cloud providers provision an image via information over specific link local addresses). If you boot a physical PC with a cloud ISO, you run the risk of exposing cloud-init to the local network, which would allow trivial takeover.

Don't some 10G/40G/100G gear support some megajumbo frame sizes now as well? Not sure about the 2.5/5G stuff though...

I can see a case where people deliberately do NOT want to use ISP provided DNS servers (to avoid DNS NX hijacking) (and/or lock to a major internet DNS server like google 8.8.8.8 or Quad9 9.9.9.9 or Cloudflare 1.1.1.1 for example)

I've previously mentioned light blocking (domain level, gTLD level), but with the increasing amount of DoH, having a means to kill off DoH and force special DNS processing, including offload to a separate DNS server (managed by a security appliance for example, say PiHole or similar) would be valuable.

The bad behavior of udev/systemd was a topic of an interesting twitter thread...

There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.

The suggested debian package qrencode seems handy for terminal use. Actually, using QRcodes to transfer information would be interesting for other uses as well, such as exporting other kinds of keys such as OpenVPN. As a remote support measure, if a config is causing issues that prevent remote login, having a local login being able to emit the current config as a QRcode might be interesting...

Wait, Argo tunnel uses Cloudflare's WARP VPN system, which under the hood is basically wireguard...

One might need to differentiate between transparent bump-in-the-wire type squid deployments, and running it as a known proxy (delivered via DHCP and an onboard PAC file). Plus any kind of speedbump captive portal. I know one place specifically uses it to force clients to expose connecting hostname due to the use of the CONNECT command for TLS connections, for passive logging on the wire. Which will get interesting with the emergence of DoH and DoT in mainstream browsers, and enterprise efforts to kill that off.

Actually somebody made a nifty websocket tunnel named wstunnel (similar to stunnel conceptually, but websockets is more natural for tunneling generic binary protocols thanks to webRTC...) that seems to work alright for Wireguard.

As long as the local nginx is not listening on the external interface on udp/443, functionally there should be no limitation to running wireguard on 443 there. A convoluted script to check that the current config has no existing 443 mapping is one solution, but that seems a bit fragile, and wouldn't really tell you where in the config the blocking 443 instance is.

Just to confirm, HTTP proxy in this context being nginx being a reverse proxy frontend for GUI and API HTTP servers, likely living on localhost bindings, right?

I think Intel now even recommends using Brocade 1gigabit modules for SFP+ modules when needing to down grade a 10G port to gigabit now, since they no longer manufacture 1G modules, so this is bound to bite people. Perhaps default to adding the allow_unsupported_sfp=1 for the various intel drivers perhaps?

Apparently Linus loves Wireguard as well now.

Added a child feature request for iPXE.

If you are going to do this, then there's the related issue of whether or not to put in PXE/gPXE/iPXE related stuff to support netbooting things.

Algo VPN, the premier personal IPSEC VPN distro is now preparing to bake in wireguard. Admittedly their distro is intended for disposable VPN VM's but they seem to think wireguard is is close to production ready. It seems they are moving to wireguard for android client connections.

I wasn't sure if we were maintaining our own package or not. If we're pulling updates from Debian security updates directly, then I see no problem. The researcher is still collecting and analyzing the fuzzer run so no published reports as of yet.

fair warning, there's a security research currently fuzzing tcpdump who has been finding some stack overflow bugs so expect a package update or two in the not so far future...

straight firewalling won't help if the logon attempts still come from a presumably trusted LAN. I like the idea of at least a temporary lockout to prevent mass attempts when someone is running a big password list, though the utility of this naturally drops if VyOS can be fingerprinted before the attempt and the instance runs with a default password, but that's a sysadmin problem.

How about

Q82 Wireguard?

I suppose I should also mention that I am also using a proxy PAC file hosted on the internal lighttpd instance as well over HTTP (again, can't use HTTPS due to certificate trust issues for unknown client PC's) which is important due to DHCP server URL designation of a PAC/WPAD file currently.

I do use squid in production, but without the hardcoded blacklists, rather my own local list only, and as an explicit proxy with a rejection message locally hosted as HTTP on the inbuilt lighttpd instance (can't serve HTTPS rejections because of certificate trust issues).

This could be possibly used for targeted Wake-on-LAN packet relaying as well...