Live data from Hacker News

Self-hosting a NAT Gateway

awsistoohard.com

61–70 of 130 posts

Re: Self-hosting a NAT Gateway

#61
The article seems to perpetuate one of those age old myths that NAT has something to do with protection.

Yes, in a very superficial sense, you can't literally route a packet over the internet backwards to a host behind NAT without matching a state entry or explicit port forwarding. But implementing NAT on it's own says nothing about the behavior of your router firewall with regards to receiving Martians, or with regards to whether the router firewall itself accepts connections and if the router firewall itself isn't running some service which causes exposure.

To actually protect things behind NAT you still need firewall rules and you can keep those rules even when you are not using NAT. Thus those rules, and by extension the protection, are separable from the concept of NAT.

This is the kind of weird argument that has caused a lot of people who hadn't ever used IPv6 to avoid trying it.

Re: Self-hosting a NAT Gateway

#62

Earlier quoted context omitted.

Because it's never once inconvenienced the average network admin, probably. I still don't get what problem it's supposed to solve for me.

There absolutely are annoyences IPv6 get rid of, that are much embedded in IT culture we only see them if we look. Port forwarding, external/internal address split, split horizon DNS, SNI proxies, NAT, hairpin routing - some of the hacks made mostly because of shortage in IP space.

The internal/external address split problem only goes away if you have a provider independent prefix, thats not in reach for many due to cost

Using both GUA/ULA together solves enough to get by, but its not ideal

Re: Self-hosting a NAT Gateway

#63

Earlier quoted context omitted.

Presumably the idea is that if you go ipv6-only you can avoid this cost and just use a firewall?

In theory.. but what happens when you want to change ISPs or your ISP doesnt assign static ipv6 blocks? Its recomnended but ISPs have no incentive to give a shit about you. Now all internal infra is not routable.

An IPv6 allocation being static or dynamic has no bearing on its routability.

Re: Self-hosting a NAT Gateway

#64

I build my own NAT instances from Debian Trixie with Packer on AWS. AWS built-in NAT Gateways use an absurdly outdated and end-of-life version of Amazon Linux and are ridiculously expensive (especially traffic). The bash configuration is literally a few lines: cat /dev/null net.ipv4.ip_forward=1 EOF sudo sysctl --system sudo iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE sudo iptables -F FORWARD sudo iptables -…

> Also, don’t assign a EIP to your EC2 NAT instances (unless you absolutely must persist a given public IP) as that counterintuitively routes through public traffic. Just use a auto-assigned public IP (no EIP).

Could you point me to somewhere I can read more about this? I didn't know there was an extra charge for using an EIP (other than for the EIP itself).

Re: Self-hosting a NAT Gateway

#65
post #12

Earlier quoted context omitted.

> I've seen claims of providers putting IPv6 behind NAT, so don't think full IPv6 acceptance will solve this problem. I get annoyed even when what's offered is a single /64 prefix (rather than something like a /56 or even /60), but putting IPv6 behind NAT is just ridiculous.

What is a single /64 prefix not enough for?

Multiple local networks while still using SLAAC.

Re: Self-hosting a NAT Gateway

#66
post #61

The article seems to perpetuate one of those age old myths that NAT has something to do with protection. Yes, in a very superficial sense, you can't literally route a packet over the internet backwards to a host behind NAT without matching a state entry or explicit port forwarding. But implementing NAT on it's own says nothing about the behavior of your router firewall with regards to receiving Martians, or with rega…

>Yes, in a very superficial sense, you can't literally route a packet over the internet backwards to a host behind NAT without matching a state entry or explicit port forwarding.

Don’t forget source routing. That said, depending on your threat model, it’s not entirely unreasonable to just rely on your ISP’s configuration to protect you from stuff like this, specifically behind an IANA private range.

Re: Self-hosting a NAT Gateway

#67
post #25

Earlier quoted context omitted.

"NAT instances" That's what you did before AWS had the "NAT Gateway" managed service. It's literally called "NAT Instance" in current AWS documentation, and you can implement it in any way you wish. Of course, you don't have to limit yourself to iptables/nftables etc. OPNsense is a great way to do a NAT instance.

I believe the NAT instances also use super old and end-of-life Amazon Linux. I prefer Debian Trixie with Packer and EC2 instances and no EIP. Most secure, performant, and cost effective setup possible. > NAT AMI is built on the last version of the Amazon Linux AMI, 2018.03, which reached the end of standard support on December 31, 2020 and end of maintenance support on December 31, 2023.

We can follow the documentation for setting up the NAT instance on any distro. I tested with Rocky Linux 9 and it worked.

Re: Self-hosting a NAT Gateway

#68

I think it might be as simple as ipv4 is just nicer to look at…maybe we should have just done “ipv5” and added another block. Eg 1.1.1.1.1. I know its stupid, but ipv6 addresses are just so hard to remember and look at that I think its just human nature to gravitate towards the simplicity of ipv4.

How did you access HN? is it by typing its IPv4 address?

Re: Self-hosting a NAT Gateway

#69
Fwiw, the solutions mentioned here don't seem to properly secure the kernel's network stack against common attacks (rp_filter, accept_redirects, accept_source_route, syncookies, netfilter rules, etc). Ask your local security guru to harden the instance before deploying.
Post reply on HN