Which is kind of ironic, because you don't get that with most wireline connections, as they're all done through IPv4 NAT.
[0] Comcast is surprisingly good here -- they'll give you a /60 (16 /64 networks) if you ask for it with the right DHCP option!
Can you go into more detail or point me to instructions? I'm on Comcast and would be interested in getting v6 at home.
I run a little OpenBSD router and my dhcpcd.conf is here [1], but I've done this before on a Linux router box too -- here are some instructions from Arch's wiki [2]. IIRC, the stock firmware on my old consumer router was also able to request a prefix and advertise it on the network.
[1] https://gist.github.com/cfallin/e5865a6a93c75ace8d26d6a85287... [2] https://wiki.archlinux.org/index.php/IPv6#Prefix_delegation_...
I actually played with NAT64 for a bit (IPv6-only internally, all IPv4 space is mapped to a special /96 in IPv6-space and NAT'd at the router, and local DNS server on the router returns translated AAAA records for IPv4-only hosts), but dropped that when I simplified my router config. It works, it just takes a bit of config :-)
Any user that wants more than a single subnet at home is supposed to receive a /48 by the same recommendation base. A lot of ISPs settled on /56s. Comcast is a bit more stingy than some.
That introduces a whole other set of problems.
And finally, the space is huge -- an ISP would typically get a /32 at least (Whois says that Comcast is using a /26 just for the Bay area), so if every customer gets a /60, that's 2^28, or 256M, delegations. (With the /26, Comcast could hand out 16 billion /60 delegations to their SFBA subscribers.)
[0] https://www.ripe.net/publications/docs/ripe-690#4--size-of-e...
DDNS is something that I once thought would be an artifact of a less civilized time, but ISPs gotta upsell, I guess.
At the very least, IPv4 fallback takes a few seconds for each DNS query, and I've experienced it failing completely in some cases (can't recall if I ever figured out why). So regardless it's a PITA when it happens.
I tried disabling the option for it to advertise itself as a DNS and instead insert the local IPv4 address in the DHCP options but to no avail, clients still ended up with public IPv6 as main DNS.
After a few hours of trying to fix it I just turned off IPv6 again.
If you set a machine to try just one IP address per second in IPv4 you'll explore a significant fraction of the whole public address space per year. In IPv6 doing that is extremely unlikely to find even a single valid address to connect to in a human lifetime.
SSH is normally not enabled, either.
sudo ufw default deny incoming
and your laptop is now secure.
You can configure firewall rules on that.
In fact, the default is almost always to disallow all inbound and allow all outbound.
Practically, my laptop is in some Wifi network and has an IPv6 address, but that isn't accessible from the outside because the Wifi/router box blocks incoming connection. That is a wise decision overall, but unforunately replaces the "can't connect because NAT" by "glorious IPv6, bit still can't connect".
And I'm not the owner of those boxes.
I've had a static IPv4 subnet allocation from AT&T on AT&T U-verse, and tried using it on a couple of consumer routers for the local network. Well, guess what — all these devices from major brands that are called "routers" don't actually route between the interfaces, after all — all they did was NAT between my public IPv4 allocation and the main IPv4 address assigned by DHCP. And disabling the NAT simply disconnected the networks — instead of rounting one interface to the other. I actually opened up a support ticket with ZyXEL, which got escalated to their engineering managers, and they did confirm my finding that their routers had a bug in sysctl settings that stops them from routing the interfaces (e.g., sysctl net.ipv4.ip_forward not set to 1).
Anyhow, back to T-Mobile US IPv6 on a hotspot — when I originally tried ssh'ing back to my own box via the public IPv6, things didn't work, either; but I then found out that it was some sort of a local policy on the local machine, because another laptop without a firewall was able to receive connections on IPv6 from the internet without any issues.
Yes, and that precisely why I use it in my home network, and will continue to use is with IPv6. I explicitly don't want any IP addresses in my green zone to be directly accessibly from my red zone.
You need to be using a firewall. NAT is just an extra, useless, complicated and unnecessary thing to be adding to the top of that; one that makes it hard to understand how your network is even working, and which makes it harder rather than easier to secure.
Since you already have a firewall you can just add a single rule that block incoming connections and that's all you actually need.
However, NAT is just a mapping from an internal IP to an external Port number. With pure NAT, once you have created a connection to the outside, anyone can send packets to that external port, and have them delivered to your device.
Of course, this mapping is inherently lossy. You are mapping the port space of one device onto N devices. This does mean external IPs can only send your devices packets on ports they have previously used as source ports, but you are still not safe. You might own devices that, for example, have vulnerabilities in their networking stack. Not that rare. You also might not want to disclose the number of devices active in a network, allow them to be fingerprinted by their response, or similar. Some UDP client applications might also not check the IP addresses of incoming packets. UDP server applications also commonly use the same socket for connections to other hosts as it listens on.
So, to elaborate on that last example, you might run, say, a video surveillance server. It might listen for RTP on UDP port 12345. It then uses that same socket to send a UDP packet to licensecheck.example.com. That packet will have a source port of 12345. NAT will then map internal_ip:12345 to external_ip:xyz. Anyone can now view your cameras on external_ip:xyz.
So either way, you'll want a stateful firewall. Deny incoming, allow outgoing. That's what firewalls are there for, and that's what gives you your security, NAT or no NAT.
$ telnet <ip> <port>
$ ip route add 192.168.1.123/24 via 123.45.67.89
$ telnet 192.168.1.123 <port>Indeed, I never said otherwise.
What I'm saying is that I want to disallow all incoming connections to any machine that isn't in my yellow zone, and selectively forward some traffic to servers in my green zone. I can absolutely use router and firewall rules to accomplish that. But when I do, I've essentially implemented a NAT.
NAT != firewall
Again, assuming I am not running any special software, what sequence of commands would you type to send a packet to 192.168.1.123 natted behind 123.45.67.89 ?
https://tools.ietf.org/html/rfc2663 might bee a good start to see where flaws are and how it works. And it's also a great way to see how a destination machine that you're talking with can puncture through your NAT, cause you did already.
And Pwnat didn't strike you as "interesting" in that it could join 2 internal networks as if they were the same collision domain, but not really?
Most people when they say NAT they mean PAT, that solution translates basically takes an outbound connection, it allocates a port and maps that port to that local computer.
That creates an illusion, of security, but that's all as a side effect, NAT inherently doesn't care about security. There are multiple ways to bypass it, most known is UPnP where hosts can actually request to open an inbound port.
The correct way to block inbound traffic is actually to use firewall. If you have a statefull firewall (currently pretty much all of them are statefull) you basically block inbound traffic to your network and that's it.
UCLA has /16 address space and it doesn't use NAT it just gives static IP addresses to computers. By default all incoming communication is blocked, but you can submit request to have certain ports opened.
Also from my own experience, if you have network with multiple devices, and you want to do something more advanced like traffic shaping, NAT actually makes things much more complicated. You need to keep in mind if you're doing filtering before or after NAT is applied.
For example I had a person on my network catch a virus and started sending mail, which got my mail server blacklisted. So I decided to block outbound connections to port 25, forcing everyone to use local SMTP server. In PF the filtering rules apply after NAT, so at that point the user has the same IP as the server. To correctly filter I need to tag the connection when NAT happens and then perform filtering on tags. Without NAT I could simply just use source IP address to do the filtering. Things become even more complex when you also want to do QoS and label traffic.
To do NAT you do need firewall, and if you have a stateful firewall you can just do the filtering by firewall. NAT was never designed as a security feature and shouldn't be treated as one.
Think of it like this. You need to go to the internet for something. Your NAT will just kludge the packet to make it look like it came from the NAT machine, altering the port and IP.
That port and IP combo needs to get back to your PC so the router keeps the mapping it used in a table and looks up all inbound packets to match on that table.
So if you have sent a packet, you’ve opened a random port.
NAT tries (lazily) to use the source port that matches the destination port. So if you ssh outbound; most NAT implementations will open port 22 to your machine.
But the stateful firewall that usually comes with your router will block random inbound connection attempts or packets from your destination that are not acknowledged.
Tbh, NAT+firewall doesn’t give you anything extra (security-wise) than a plain stateful firewall gives you.
With multiple hosts it’s going to depend on the implementation, but it will likely forward it to something it thinks can handle it, because most NATs try to be as transparent as they can, to not trip up unknowledgeable consumers.
NAT is not, and has never been a security measure. Just run a damn firewall if you want to drop incoming traffic. The firewall gives you everything you want; you aren’t gaining a damn thing from the NAT.
NAT itself would only be security-through-obscurity.
Including HN, moments before reading this page.
It's true that outside networks usually cannot send a TCP SYN to your local network without IP spoofing or other hackery.
But a firewall is sufficient; there is no need for network address translation.
If you have a router with NAT and without (stateful) firewall or RPF, and such router receives a packet on wan port with dst address from your private LAN range, then such packet is just passed to your LAN (as NAT does not apply here). Obviously, such packet is unroutable on general Internet, but could be send by our ISP or by other customers of your ISP if they are on the same network (e.g. wifi AP) as your wan port. There are also more sophisticated ways, like abusing automatic decapsulation of packets (if enabled). Fortunately, in most cases a router with NAT also has enabled stateful firewall, so this is moot.
You buried the lede here. This makes a huge difference. I am much more willing to trust my ISP (a major company who would be quickly found out if they were trying to hack random people) than the entire set of people on the global internet.
If someone (your ISP, someone who compromised your ISP's router, someone who happens to be your neighbour on an ISP with misconfigured routers ...) sends a packets directly addressed to your internal address range to your WAN interface, that is of no interest to the NAT function and will simply be routed to the LAN interface unchanged.
That is: Unless the device happens to also have a stateful firewall that would prevent that. But then, the firewall would work just as well without NAT.
This is exactly what the job of a firewall is.
NAT is a hack due to IP address exhaustion. Any security is a side effect. Nothing that says "NAT" on the tin is obligated to protect you.
NAT on your own network if you really drink that kool-aid is fine. I'm more concerned about CGNAT. If ISPs implement NAT (called CGNAT), it means you can't accept incoming connections without your ISP approving/supporting it. I don't want to have to beg my ISP to open ports for me and question/approve why I'm doing it.
Well, I agree (if you include the router in that). I never asserted otherwise. In fact, this is how I've implemented my NAT.