Why do you think NAT is part of a firewall? NAT and firewall are two completely separate things that can exist independently of each other.
Also overlapping ranges are an orthogonal issue that can occur with IPv6 private network range as well.
IPv6 brings not only bigger address range but also a big bag of other things that one cannot ignore, are complicated and which are often a source of problems. That's why people stick with IPv4 even at the cost of NAT, because the number of things they have to care about is much smaller.
> NAT and firewall are two completely separate things that can exist independently of each other.
This is kind of like saying that web browsers don't have to have a graphical interface. Or that a web browser doesn't necessarily support HTTPS. It's correct, but not practically correct.
The reality is that essentially all NAT software you'll actually encounter will be integrated into a stateful firewall because the two systems share so many functions that most projects and products that do one will also do the other. If you have a system with NAT set up and there is no packet filtering, it's most often because you've intentionally gone and disabled all the packet filtering, not because you need separate software for it.
It is important to understand that NAT doesn't have any inherent security to it, but criticizing people for talking like NAT is a feature built into firewalls when NAT is overwhelmingly a feature built into firewalls is a pretty unfair reading when we're talking about general deployments. Even with the technical audience of HN, we're not discussing carrier grade NAT here or other highly specialized or exceptional deployments.
SNAT absolutely has intrinsic features that are utilized for security purposes.
This isn't to disagree with your main point. Many people in this topic have an oddly narrow definition "firewall" that tends to fall along the lines of "whatever makes me right and you wrong".
A statefull SNAT implementation itself has most of the characteristics of a "firewall".
> SNAT absolutely has intrinsic features that are utilized for security purposes.
Yes, but those features aren't there because they're security features. They're incidental to how NAT functions. It's not inherently secure. The intention of the design is to permit hosts on a network that is not Internet-routable to be able to send traffic that is Internet-routable. That's not a security feature. That's allowing traffic to pass that would ordinarily get black-holed.
> A statefull SNAT implementation itself has most of the characteristics of a "firewall".
Sure, but you should recognize that that's the same as saying a stateful SNAT implementation is an incomplete stateful firewall.
If your goal is to use private addresses, you should use NAT. The point is that if your goal is security, then you should configure a firewall.
Don't expect software that isn't designed to provide you security to provide you with any security.
SNAT is often a feature built on a network stack that also provides other "firewall" functionalities like filtering packets. Configuring SNAT is configuring a firewall? Or is only dropping packets a firewall? Or does the device need "firewall" printed on it? Does a device that has "firewall" printed on it still count as a firewall if it's not configured to filter packets? What type of filtering makes it a firewall? If an SNAT implementation drops packets is it a firewall? Is a linux/windows/bsd box with multiple interfaces a firewall? What if I slap "firewall" label on the box; a firewall now?
SNAT can be used to mask source IP and that can absolutely be utilized strategically as a layer of "security".
If your ISP delivered you a packet with a destination address of 192.168.0.5, there's a good chance your router would deliver it to that device without consulting the port forwarding table. In this way, NAT isn't a firewall and you're relying on your ISP's routing policy as your actual firewall.
If my ISP sent me a billion dollars I would be a billionaire.
What's represents a "good chance" the router is so grossly misconfigured as to allow inbound traffic no destined for the IP assigned to the WAN interface to be routed to one of the internal interfaces? I wouldn't be surprised, but what's a "good chance"? Is there data on this?
A typical, correctly configured SNAT implementation would most likely have the characteristics commonly attributed to a "firewall". An incorrectly configured network device may not have the characteristics commonly attributed to a "firewall", regardless of its ability to actually inspect and drop packets(which just about every commonly used OS network stack can do out of the box).
But even an SNAT implementation without typical "firewall" characteristics has intrinsic characteristics related to security; such as source IP masking. Which doesn't even need to be private.
> when NAT is overwhelmingly a feature built into firewalls
This is just not correct. NAT and firewall are simply orthogonal concepts and can and often are deployed separately. A simple example is your average small SOHO router, which usually has NAT but quite a lot of them lack a firewall.
Yes, on both macOS and Windows 11. On Mac you have to create/use a simple .mobileconfig profile. On Windows you have to separately provide both IPv4 and IPv6 addresses.
Blog posts where I find quality really shows are usually about something I know next to nothing about how it works. A badly written article usually either goes really shallow or skips some facts when going into depth and requires catchup elsewhere to actually understand it. The lidar article from Main Street Autonomy goes beyond basics and explained everything from the ground up in such a connected way that it was a real pleasure reading it.
I'd investigate why it won't run with debug info in the first place. That feels like the core problem here, because it prevents you from using some debug tools.
Of course that may require digging down pretty low, which is difficult in itself.
Edit: also there's split-debuginfo which puts debug info in separate file. It could help if the reason you can't run it is the debug info itself. Which feels unlikely, but :shrug:.
I tried to generate split-debuginfo, and it created another compiler issue in another library, haha, and I was too tired to dig more into it.
Curious if it's possible could it be because of protobuf implementation, which is used between UI and the server, and my error is occurring on the UI side.
So, after reading a bit, this is what I find
>Deterministic serialization is not canonical. The serializer can generate different output for many reasons, including but not limited to the following variations:
> The binary is built with different flags (eg. opt vs. debug).
My knowledge on this is pretty limited, so I could be wrong. But, this could be a reason. Maybe someone more knowledgeable on this matter can shade some lights. And I should've studied more on this before ... heh.
Not related to OP, but debugging is often about finding where an invariant is broken, so it feels like using LLM to navigate a debugging loop may be useful as it's not a complicated but repetitive task. However in the morning I struggle to imagine how to do that.
I use claude code all day long to debug gnarly legacy code. Sometimes in languages I barely know. It works great especially as a second opinion or to get unstuck. It is very fun but can be addictive and exhausting.
More specifically I will stub out a simple unit test by hand to zoom in on where I think the issue is. It then turns into an exhilarating and wild ride from there.
The problem with making invalid states representable is that the app logic must be able to handle it, everywhere. Which means you have to always take it into account when reasoning about your app and implementing it, otherwise it will blow up in your face when the invalid state actually occurs. Which means your state machine is inherently larger and harder to reason about.
To illustrate what I mean, take the null pointer. It's essentially an Optional<T> and in a lot of languages it's involuntary, meaning any value is implicitly optional. What happens when something returns null, but in some place in your logic you don't take it into account? Null pointer dereference.
I'm not convinced, because you have to deal with invalid state in some way or another in any case.
If you have to delete some record referenced by other records using foreign keys, you'll have to handle the complexity in any case, except if this is enforced by the database, you'll have no choice than to think about this upfront, which is good. It might lead you to handle this differently, for instance by not deleting the row but mark it as deleted, or by changing the id to some "ghost" user.
If you don't do this, all the complexity of not having to deal with the inconsistencies when you are creating them will have to be encoded in your code at write time, with null or exception checks everywhere.
Constraints encodes what safe assumptions your code make to be simpler. If an assumption needs to be relaxed, it's going to be hard to change things as you'll have to update all the code, but the alternative is to make no assumption at all anywhere, which is hard too and leads to code that's more complicated than necessary.
And then what does an invalid reviewer_id mean? Was this caused by a user deletion? Or a bug somewhere? Or some corruption?
Bonus: some commenters here write that it can depend on which programming language is used, I don't think it matters at all. You'll have to handle the null or dangling values in any case, whether the language guides you for this or not.
Also overlapping ranges are an orthogonal issue that can occur with IPv6 private network range as well.
IPv6 brings not only bigger address range but also a big bag of other things that one cannot ignore, are complicated and which are often a source of problems. That's why people stick with IPv4 even at the cost of NAT, because the number of things they have to care about is much smaller.