This and the comment it replies to make the categorical error which is to assume that NAT exists as part-and-parcel to firewalling. This is not the case. Many American university and corporate networks do still adhere to the end-to-end principle by giving every device a public IP address. They can do this because they are among the few legacy entities that actually have enough for their needs, such as a Class A (aka /8) subnet on Legacy IP. At the same time, these entities employ firewalls that don’t allow unsolicited inbound traffic (and sometimes also block disallowed outbound traffic).

NAT is not a firewall, and the OP correctly points out that by using NAT or CGNAT, the end to end principle is demolished, with no way for the victims to recover. OP mentions “firewalls” exactly twice, to compare how they are not firewalls and are still necessary in spite of NAT. Nobody is credibly suggesting that everyone should switch to IPv6 without a firewall. Every single domestic router for the past two decades has included a firewall, and that would not change in an all IPv6 world.

I wish to reiterate an example I’ve used in the past, which is that the most famous address in the USA is 1600 Pennsylvania Ave, Washington DC. Anyone can send letters and parcels directly to this address as-written, with no need to rewrite the address to first arrive at the Secret Service. And yet, all such parcels and letters will be thoroughly scrutinized by the Secret Service anyway at an off-site facility, and some indeed will be let through to the occupants of the residence. NAT is address mutilation, and the United States Postal Service does not require nor allow that.

What are these “built in listeners” that you speak of, and which OS’s can I find this on?

Also TCP will work before UDP. For whatever reason firewalls and such do weird things with UDP traffic.

This doesn’t really explain why troubleshooting is more difficult, but rather that firewalls often cause trouble for UDP. My question was “why would diagnosing a UDP problem be harder than anything else?”, not “why is UDP more problematic?”. I’m fully aware that some firewalls are configured with absurd parameters, like blocking ICMP, QUIC, or even TLS in some bizarre situations. But my tools for debugging network troubles have always been the same: tcpdump for passive tracing, nc to coerce an active response, and icmp/icmp6 ping for basic connectivity and MTU verification.

Whether it’s UDP or anything other protocol, those tools have proven sufficient for me. Do you use something else?

I’ll add some color to this post.

The original FTP is, frankly, a monster of a protocol. Very useful, but an anomalous protocol that even without NAT breaking the end-to-end principle, it is unlikely to have survived modern corporate firewall rulesets in any case. The fact that FTP was even ported for TCP is its own historical quirk.

BTW, that is the term which this post is missing: the end-to-end principle is the design philosophy that the network itself should not have to perform work on payloads transmitted, except to carry it towards the destination. This also implies that no fields or bits should be modified in transit, once it leaves the sender; encap/decap restores the fields so that the receiver is none the wiser.

NAT breaks end-to-end in two respects: corruption of the original sender, and corruption of L4 port numbers. Note that Legacy IP also violated end-to-end, when packets are fragmented due to MTU issues. With IPv6, fragmentation by the network is disallowed outright, and the technical case for NAT is non-existent.

There’s something to be said about adopters of NAT, that they were facing a Hobson’s choice: use NAT so that they could connect early dial-up users to the emerging Internet, or reinvent the 20 year experiment of the Internet so that it could scale properly. In 1995, IPv6 did not exist so they made the only real choice available.

In the year 2026 though, that argument doesn’t hold water: it is a choice to continue to ignore the dual-stack and IPv6-only internet. There’s a quote that all sufficiently complex technical problems are in-fact political, and this is that: the modern case for Legacy IP and NAT is rooted in inertia, resource scarcity (eg hyperscale cloud companies buying up IP subnets), and recalcitrance by professionals that abdicate their responsibility to their clients to pursue the available technology.

There is no colorable technical rationale for why IPv6 best practices cannot be adopted today for most organizations, when all network hardware, all major consumer and enterprise OS’s, and all mobile phones support v6. Note that I said “best practices”, because a minority of orgs such as certain American ISPs have undertaken truly bonkers decisions that are putting us on track for the very same sins as Legacy IP.

The fact that some ISPs assign nothing but a single /128 via DHCP6 is absurd: this malpractice perpetuates the same problem as NAT44, except that there’s no good excuse for it. Even the most delusional of ISPs will never run out of /128 addresses in their assigned /32. Per best practice, even handing out /48’s to customers is not a problem either, because that’s 65536 customers and if that’s really a problem, just ask the RIR for another /32, which they can do as RIR dues-paying members. There is no practical limit, except that some people just cannot math properly to see that there’s no practical limit. When a technical solution to a technical problem fails because of innumeracy by those tasked with implementing it, then that’s so much worse than any 1990s workaround.

I’ve harped a lot about IPv6 because its strength today is that it’s technically competent, future-proofed, and most importantly, practitioners that saw the first travesty of NAT will not allow a redux to play out with IPv6. The technical reasons to deploy NAT66 are non-existent: it is always a workaround for political issues.

I can (just barely) accept NPTv6 as a like subnet-for-subnet mapping that does not harm L4, but that’s still glossing over a political issue. IPv6 gave network engineers real choices in numbers and administering their networks, and while some will squander it, I will be encouraging people to not let that happen.

Why would UDP be any more difficult than TCP (or anything else) for troubleshooting? If nothing else, it should be easier because there are no stateful connections and every packet is “fire and forget”. Now, as a tunneling technology, WG might be more difficult than a simple client/server socket-driven application, but that just means some routing tables need to be inspected and you have to understand IP subnets. In any case, you’d still want to obtain packet traces from both ends of the WG tunnel.

The thing is, if you don’t wish to port-forward on Legacy IP nor open firewall ports for IPv6, then the only other option is to reach out to some sort of relay server. But whether your own VPS fulfils that role or you use Tailscale’s DERP/TURN relays, the same class of latency and bandwidth issues will still erupt. So you’d still have to debug them, although you presumably would have better visibility into diagnosing issues with your VPS relay.

Generally speaking, if Tailscale isn’t working for you, then all other solutions will increase in complexity, not decrease.

Answering the ultimate question, I operate and secure my SSH server, with port 22 open only for IPv6 inbound. There’s no NAT, so I don’t have to deal with debugging odd port mangling. The SSH server only allows key auth, and all password attempts are logged and blocked, because there can’t be any legitimate traffic like that. On this SSH server would be my mounts for backups.

IIRC, the USA Social Security Administration’s website operates somewhat like this, because they seem to still do batch processing (a la mainframes) during the evening hours. As a result, they prevent people from logging in so that they don’t get interstitial data about their public pension.

Having conducted technical interviews after managers have screened the candidates’ resumes, I second this. Businesses absolutely look at example works, precisely because it’s what they care about: it doesn’t take a leap of the imagination that if someone has churned out excellent work for hire, that they can do it again once hired on.

It’s a bit harder for prospective employers to take someone at their word without works that they can point to, or can succinctly describe said works in sufficient detail.

I skimmed this article, but I’ll revisit it later because MPU protections have always intrigued me, in terms of being a much smaller subset of the protections afforded by an MMU. That said, for work projects, I’ve only ever been able to make use of MPU regions for coarse-grain protection (eg prevent the DMA-dedicated regions from being accessible by everything) and not for per-task protection. So I’m always interested in ways that more isolation can be applied, precisely because it keeps code honest, which isn’t a bad thing. It’s no different than having software asserts.

This looks amazing. That said, you may want to have a look at rules 7 and 8 for this community.

Contributors: Claude

Please kindly see Rule 8 of this community and its associated post.

In the space of mini PCs/NUCs, this does seem comparable. But bear in mind that the entire space of “home server” is a lot bigger than NUCs. After all, not everyone just wants to host an NVMe drive or two; they might want to fit some cheaper SATA SSDs or even spinning rust, as part of a cascade of stroage, with caching on SSDs and other nice things.

Likewise, the dual LAN ports with 802.3bz support is nice, but the reality is that most networks are only 1 Gbps with some devices supporting 2.5 Gbps. Quite frankly, for server use that actually needs one or both port’s bandwidth, the link would likely be better served with SFP+ slots, because of better compatibility with cheap enterprise switches available online, and because SFP+ transceivers run less hot than their twisted pair counterparts at 10 Gbps. Heck, you could even use a 40 Gbps QSFP+ NIC, which only requires a x8 or X4 PCIe slot (depending on PCIe generation of the NIC). On that note, a single PCIe slot is nice, but it does preclude the use of a double-wide GPU for transcoding use.

I would sum all this up as lacking expandability. Yes, it can be expanded somewhat. But for folks that want the capacity of an ATX-based build, this ain’t it. And for folks with abundant solar power, electricity consumption for older gen chips isn’t as much of a dealbreaker. It certainly checks off a lot of people’s boxes, yours included, but that doesn’t mean that people are “sleeping on” this, because at the end of the day, if it doesn’t serve their purposes, it’s not the right box for them. In terms of price, never underestimate the cost of $0.00 that is an old, unused laptop; they make remarkably decent servers for light loads.

Also, as of this writing, only the 32 GB RAM variant is available on the USA website.

Corporations even before AI have sued each other, precisely on the premise that “your code looks like ours. We think you stole it” and then have a petty fight in court because their lawyers couldn’t hash out a settlement.

Now with so-called AI washing, it’s only going to get worse, because LLM generated code doesn’t have to be 100% identical to be considered a derivative copy of the original. It all goes back to the central question: did this copy come from this original work?

The corporate IP lawyers will be making bank off of the ambiguity.

I’ve had similar trouble understanding this aspect in the past, so I’ll share how it now makes sense to me, within the frameworks of existing IP law. IANAL.

Copyright law protects a specific, tangible work from duplication, meaning that if someone directly derives an unauthorized copy from an original work (eg scanning a book), then that’s copyright infringement. However, copyright law does not simply look at whether a copy is identical to the original. There must be an analysis of the provenance of the copy: did the copy come from the original?

Two people can separately stand at the Grand Canyon visitor center and use their own cameras to take identical film photos from the same vantage point, such that the developed film is identical in every way. And yet, neither has violated each other’s copyright, because neither photo came from the other. Person A can sell their copy to a magazine, while Person B distributes copies for free with their holiday cards. This is all A-OK.

The trouble is when somebody suspects infringement, because they see a copy that looks unusual similar to an original. If they decide to raise a copyright lawsuit, then the defense would like a way to affirmatively show that “no, our copy didn’t come from your original”. How do they do this?

In software, the approach would be to methods like the clean room approach. This is explicitly a method for legal reverse engineering, precisely to avoid copyright concerns. It works because while copyright protects a tangible work, it does not protect the ideas recorded by that work. So if somebody was given only the idea, and tasked with writing the software that re-implements that idea but without ever seeing the original, then the resulting work cannot possibly have been based on the original work. Rarher, it’s just a take on the same idea, which is allowed to be similar, in the same way as the photo of the Grand Canyon. There is no straight line that connects the supposed copy to the original work, apart from the idea itself, which copyright does not cover.

With LLMs, there is zero assurance that any clean room approach was followed. By training directly on original, copyrighted works, there is a cloud of uncertainty about whether the LLM is regurgitating parts of the original (which would be infringement) or if it actually reduced the user’s prompt into an idea, and then independently generated code which implemented that idea.

Copyright infringement poisons everything that is derived thereafter, so even the spectre of a doubt causes problems, because if GNU or whoever else builds atop questionable copyrighted software, that foundation collapse suddenly if someone brings a lawsuit to enforce their copyright. And those are pricey to defend, even if it’s without merit.

The clean room method, when followed faithfully, is a way to discourage potential litigants from even filing a lawsuit, because it’s clearly obvious that they would fail to prove a connection to the original work. Patents are a different story (where ideas are protected).

LLMs basically have the same problem as when an engineer quits and goes to work for a competitor. Will they have (accidentally or not) taken trade secrets with them and implemented those in the competitor’s product? A well-advised company would go through great lengths to make sure that engineer isn’t working directly on a competing product, to avoid a costly lawsuit. LLMs do no such mitigation.

From memory, I believe it does. But that means the bisection would give the result that the merge commit is responsible for the bug. Which isn’t wrong, but most workflows do not just blindly revert a whole merge, but would have to follow-up to surgically find and fix the bug in the merged-in branch.

So that would be yet another invocation of Git bisect. The hazard is believing that bisect is an fully automated bug finder, when it would just stop at the first merge commit if the bug came in from elsewhere.

The other hazard that I didn’t mention is a presumption that every commit – merge or not – is individually buildable and testable. For good workflows, this is the case. For some… more casual workflows where broken code is pushed and then fixes thereafter, bisect will not be able to hone down to a singular commit.

There are business, technical, and UI/UX reasons for having a client. The business case is that it clearly demarcates the service they’re selling, because it must be installed and isn’t built-in (eg Firefox VPN). The act of having the user do something means that for a brief moment, they have to concentrate on the product. Consumers have this tendency to value things higher if they were involved in its success, such as when building flat-pack furniture.

The technical side is that while a VPN is indeed just a tube that transports packets securely to the VPN servers, the fact is that there are so many ways for this to go wrong. For example, leaking DNS requests is a way to throw the confidentiality guarantee* of a VPN out the window. As can Happy Eyeballs, where the same HTTP request is sent by both Legacy IP and by IPv6; if both aren’t sent through the tunnel, confidentiality is lost.

To deal with this, the client can implement mitigations, such as setting a different DNS nameserver, as well as the (IMO exceedingly inappropriate) measure of disability IPv6 outright. These are not functions which the built-in VPN client in the OS would necessarily do, although some OS network managers genuinely will do a good job. But even more important than applying mitigations is to check for leaks! The client app can run periodic tests to make sure DNS or IP packets are always going down the tunnel, such as by checking destinations that only exist through the tunnel. Failure to pass this test should throw up huge warnings that the user’s confidentiality may be imperiled. This is table stakes for a retail VPN service in 2026.

Finally, UI/UX for a VPN requires that the whole thing be easy: users want to browse the web, download … uh… Linux ISOs, and go about their life with a VPN that Just Works ™. Most people do not want to copy a Wireguard config into the OS using a terminal. A VPN service should have broad appeal, since the fear mongering advertising suggests it’s a product that everyone online should use.

At bottom, we can say that “retail VPNs” really do need a client app. But for technically minded folks, a Wireguard config would be enough, because the endpoints would also be configured to route solely down the tunnel. Or even use an isolated netif, in the case of Linux namespaces, which is IMO quite clever.

Another word of caution: bisection will have a rough time navigating around merge commits, because those introduce nonlinear “forks in the road” that also tend to be introducing large, possibly-breaking, non-trivial changes. But if your workflow is already avoiding merge commits except when necessary, then the drawbacks are minimized.

Yet another reason to prefer linear history in Git whenever possible, because bisect will work more predictably.

That said, if you’re needing to use automatic bisection very often, this may point to a lack of a CI pipeline to validate commits automatically. After all, if a broken change is flagged before you notice, then you wouldn’t need to bisect because the system has identified the faulty commit.

Would cert-manager for Kubernetes be approximately what you’re looking for? In that particular case, it’s a service that runs in a K8s cluster, that can auto-request CSRs and send them to Lets Encrypt using one of the challenge types. It takes care of managing the returned certificates, such as renewing them before expiration and registering the private keys within the K8s key store.

I presume that you’re not already using K8s, so maybe that project will help you find the keywords to describe the sort of certificate manager that you want.

If you’re already using Debian on desktop, then Debian on a VPS makes sense from a maintenance perspective: you only have to track one set of security updates. When there’s suddenly a critical update for some vulnerability, you can update both at once because it’s the same upstream repos. Whereas with Ubuntu on your VPS, you’d have to be mindful to make sure to check back when the same vulnerability is patched there.

Do not underestimate the effort to upkeeping a server, and do try to unify your procedures so you’re spending less time doing the necessary things, and more time building up your self hosting stack.

Unirust has you covered: https://github.com/charyan/unirust

(to be clear, that’s a joke and please don’t code with that, even if it would further Rust adoption)

I’m surprised they don’t lock some things behind account logins. Is it that hard to decide what would be acceptable to no longer serve without an account?

From this most recent event, such a policy would probably need to be proposed and voted on, if the voting members of Codeberg want it that way.

The way I read their post, it’s doing double duty: the first is the announcement of the ToS changes. The second is laying out their overall position, because – by their own words – LLMs are controversial and with this announcement, they are pushed into a discussion where not everyone is on the same page. Should the LLM problem continue to get worse for Codeberg, their post is fair warning that future measures might be proposed and voted on. No one should believe that the two ToS changes alone have fully mitigated the LLM problem for Codeberg.

And I think that goes exactly to their point about communities: Codeberg fosters human communities, unlike LLMs that embody nothing, and GitHub that is commercial with a free tier. If something is going to change, it will be by community discussion and decision. In that sense, their radical transparency is exceptional.