zirias@
Developer
I now better assume you're making this up ... right?Yeah, uh, what? "NAT Security" gives us what you're claiming is... nonsense? Wouldn't this be the opposite of what you're trying to get us to understand?
I now better assume you're making this up ... right?Yeah, uh, what? "NAT Security" gives us what you're claiming is... nonsense? Wouldn't this be the opposite of what you're trying to get us to understand?
But it's pure & plain, simple aristhotelian logic applied: We do what you requested, and it points us to a source that in contrast you call unreliable & misleading... Well, your last posts were more substantial & hopefully we can continue that way. This topic is too important & does not deserve a discussion spiked with personal taunts. If you feel there is one against you, please just ignore it & keep on with relevant infos & hints. Thx in advance, sincerely yours, MjölnirI now better assume you're making this up ... right?
Well, complaints like issued in this thread come from this idea of NAT as something "helping security", which it isn't and never has been and I think it's REALLY important to understand this misconception. The patch here aims to *improve* NAT, and given the declared goal of NAT, which is *enabling* connections, it does exactly that.For crying out loud, I look away for two seconds and there's two pages worth of bickering about who's right or wrong. Take that elsewhere please.
Honestly, I don't understand the whole quarrel either.Uh, a classic, if YOU don't understand something, it's magically everyone. Only serves for self-assurance of course. But for that great secret what to search for, maybe try "NAT security". Surprise.
Seriosly, no.thinking everyone knew about the reputation of Gibson in this field
That's the thinking I consider kind of dangerous, cause this "security" is a byproduct of the shortcomings of NAT, and improving NAT will then decrease this kind of "security". The objective of NAT is to allow as many packets as possible to find their target.The question is not so much whether or not NAT was designed to provide security, although asymmetric NAT surely does improve security.
That however is a rant I can relate with, but I'd argue it's not really tied to NAT. As a firewall administrator, you maybe want to open up a specific port on a specific machine for UDP to allow a specific game to communicate. Whether you have to "forward" this port or not won't change anything in principle. A better NAT might remember a mapping automatically, so you don't have to explicitly forward something, but you still have to allow this communication. Thinking IPv6: You won't have/need NAT, but you'd probably still block any incoming packets by default and you still want to allow packets to a specific UPD port on a specific machine for exactly THAT game.The question is whether games or other applications that employ techniques to punch holes into your firewall can be considered well behaved networking applications at all. I for one surely wont tolerate such behaviour from any network application. Many games in the past used fixed (or even configurable) ports for communications, so you could just set up a port forwarding on your router and be done with it. Nowadays game developers seem to be under the impression that setting up a port forwarding is way beyond the skillset of their target audience, so they resort to using crappy p2p networking implementations like steamworks and the like, with no user configurability whatsoever, that uses ephemeral ports on both sides, thereby creating a firewall admin's nightmare (as in: it just doesn't work if you do not open up ALL ports).
Games or other network applications behaving this way are bad by design. Steamworks for example uses libjingle to find a workable connection from a set of candidates, this employs STUN which simply cannot work with a symmetric NAT, it also leaks private IP addresses and there is nothing whatsoever that could be configured by a user. In the end, the only connection that has a chance to succeed if you are behind a symmetric NAT is via a relay server, whch might introduce additional latency and that is exactly the opposite of what you'd want for the purpose of gaming.That however is a rant I can relate with, but I'd argue it's not really tied to NAT. As a firewall administrator, you maybe want to open up a specific port on a specific machine for UDP to allow a specific game to communicate. Whether you have to "forward" this port or not won't change anything in principle. A better NAT might remember a mapping automatically, so you don't have to explicitly forward something, but you still have to allow this communication. Thinking IPv6: You won't have/need NAT, but you'd probably still block any incoming packets by default and you still want to allow packets to a specific UPD port on a specific machine for exactly THAT game.
So, what's really annoying is this idea not to be able to configure the port used by a game, and games (and other software) trying to "punch holes" automatically, by just "tricking" any connection tracking. [...].
I think the complaint should be towards software behaving that way, cause yes, this software will stop working with a restrictive ruleset in place on your firewall box, whether you use NAT or not. It shouldn't be an argument against improving NAT in a way so it can automatically route more packages correctly. Please just decouple filtering from NAT.
I might be mistaken here as I don't use that kind of crap, but my guess is that even consumer grade routers these days more and more use symmetric NAT. There is nothing wrong with automatic approaches in general, as long as developers give the user at least the option to make it work, when these mechanisms fail.Definitely a braindead thing. Although I understand the motivation to offer some "automatic" behavior when operated by someone with no knowledge at all, behind your typical consumer router. If there is no alternative way to just tell this thing "listen on port XX", it's broken crap.
All I'm saying is, this isn't really related to NAT, it will give you headaches configuring your firewall without NAT as well.
They use it for IPv4 as there is just no other option. They nowadays support IPv6, of course without NAT. And ISPs offer more and more "ds-lite" where you get IPv4 only through a tunnel (over v6) with a private address that is *again* NAT'ed at the ISP.I might be mistaken here as I don't use that kind of crap, but my guess is that even consumer grade routers these days more and more use asymmetric NAT. There is nothing wrong with automatic approaches in general, as long as developers give the user at least the option to make it work, when these mechanisms fail.
firewall_type=workstation
) that answers ICMP of my ISP (to debug a problem should they need to), and deny all others. That's really simple. Of course, now that they NAT me, that makes no sense, but when they give me IPv6, I could do that easily.The only RFC you need to know is RFC 1149 / RFC 2549RFC4941