To clarify, what I meant is that with TCP, I can set up a two-way communication channel, even if I'm behind a NAT/firewall I don't control. As far as I understand, with UDP this is harder (i.e., does not work with all NAT types), because UDP does not establish a connection, and it does not provide a two-way communication channel. However, I am not up to date on NAT traversal techniques, so I might be wrong.

Which was maybe a problem 20 years ago.

But probably not.

Not sure why you say that, UDP conntracking has been around for a long time.

I suspect that what andreasvc meant is that the default "NAT" configuration of most consumer-grade gear is such that it will block UDP (unless some other mechanism such as UPnP is used)...

That's true for TCP as well. Almost all consumer-grade routers block all incoming connection attempts, not just UDP.

From a stateful firewall's point of view both UDP and TCP have state.

Right. I was assuming that the context here was connections being initiated by the client (as most are).

... in which case blocking is not an issue. Consumer-grade NAT hardware will no more block client-initiated UDP than it'll block client-initiated TCP, at least not without extra configuration.

But it doesn't. Consumer gear NATs UDP pretty much as nice as it does TCP.

Hmm, perhaps you are right... I switched from consumer gear to more "enterprise-y" gear a few years back, so my data points may be a bit outdated.

I've been using normal consumer routers for NATed home connects since 2004 or so and I've never had an issue with outgoing UDP. It's required for basically every video game after all.

If NAT blocked UDP, the DNS client on home computers would never work.

I think most routers set themselves as the DNS server, so NAT is not in effect (the computer only sends the request to a local address) unless you define a custom DNS server, which isn't common for home users.

That said, I've never seen a router that didn't allow UDP packets to flow back to the origin client.

> I think most routers set themselves as the DNS server

DNS forwarders like dnsmasq are a relatively recent inclusion in home routers. Sure, they've been there for 10 years or so, but they weren't there for the 5+ years before that. Before Linux took over the embedded OS on home routers, the DHCP servers just passed the DNS configuration that the WAN port got from the ISP, and you can still do that now if you want. That's why nslookup.exe and dig still work on your workstation when you specify an external DNS server instead of the one your DHCP server on your home router gives you.

> That said, I've never seen a router that didn't allow UDP packets to flow back to the origin client.

Which is the point I was making.

Most consumer-grade gear can easily handle two-sided NAT transversal with merely a STUN server (no UPnP or relaying required).

Why does it matter that IPv6 is old, if your users are only using IPv4 ?