5 ms·
This, whilst technically correct, isn't necessarily end-users experience of things. Yes NAT doesn't block packets, however without explicit configuration traff
by raesene9 8y ago
This, whilst technically correct, isn't necessarily end-users experience of things.
Yes NAT doesn't block packets, however without explicit configuration traffic from the Internet will be very unlikely to flow into an RFC1918 addressed network from the Internet.
So effectively it does prevent traffic inbound in the same way a firewall does.
Yes you can punch holes in NAT, but that's an explicit action (well side-stepping the insanity that is UPnP) for for non-technical users sitting behind a NAT router will effectively mean that they're unlikely to receive direct inbound network attacks from the Internet.
- throwaway2048 8y agoYou can achive precisely 100% exactly the same functionality with a firewall without NAT, indeed you need that sorta functionality to implement NAT to begin with. All you need is a default deny inbound traffic rule, this isnt some kind of arcane thing that is so much harder than NAT for end users.
- raesene9 8y agoOf course you can, the point I was making was that NAT provides effectively the same outcome, not that it wasn't possible with a firewall.
- vetinari 8y ago> Yes you can punch holes in NAT, but that's an explicit action (well side-stepping the insanity that is UPnP) for for non-technical users sitting behind a NAT router will effectively mean that they're unlikely to receive direct inbound network attacks from the Internet. Hole punching the NAT does not mean that the user will configure port forwarding. It means that the outside is able to send packets inside, without any explicit user action. It works, because most NAT implementations do not check the source IP address, so when user sends packets from port A to ip X, and the router receives packets to port A from ip Y, it will dutifully forward them, even if they are not related.
- beagle3 8y ago> without any explicit user action. It works, because most NAT implementations do not check the source IP address, so when user sends packets from port A to ip X, and the router receives packets to port A from ip Y, it will dutifully forward them, even if they are not related. That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections. NAT is not a firewall, and many NAT implementations will let packets in through _if_ you know the internal IP, _and_ all routers along the way including the last one support source-routing -- which is definitely not most setups. Furthermore, quite a bit of the home users using IPV4 these days are behind a CGNAT, which makes this even harder, as you need to source route through multiple NATs. Hole punching without cooperation from the inside is not impossible, but it is extremely hard these days, to the point that unless its an ultra-targeted attack, no one is likely to try.
- vetinari 8y ago> That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections Of course it is true. The true thing you wrote is, that Linux is one of the few implementations that do check the source IPs. However, even if many home routers do run Linux, it does not mean that they use Linux's NAT. Many do not have enough CPU power to route/NAT at the speeds needed, so they have hw acceleration for that, and that is a separate implementation. But hey, why do you think hole punching is a thing? Because it works, relatively large scale.
- beagle3 8y agoHole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen. Care to point to 3 examples of common home routers that do not check source IP? I’ve verified many TP-Links, Linksys (when they were owned by Cisco) and Netgears, and all used the kernel to NAT (and yes, they couldn’t do the 1Gb while NATting - usually 300-700 or so. And much lower if you use IPSEC)