Hacker News Reader

Comment by mshook | Hacker News Reader

They can, it's called firewall punching...

Skype does that routinely: ever wondered how it can setup a point to point connection without port forwarding?

So to agree with PP, NAT is not a firewall...

I believe that's called ICE. and still needs both clients aware that theyre about to connect, and making outbound connections to each other with the goal of opening up sourceports.

This does not negate the fact that NAT(PAT) provides protection against directly connecting to a device.

If you know a bug in the DNS resolving stack of the client, you can make it send a query to your DNS server and exploit it to establish a connection. So no, it doesn't have to know it's about to connect.

A query is easily triggered by sending an email with a an external picture embedded or something like that.

Nothing NAT/PAT can protect you against.

But why would the client use _your_ DNS server? It will just use its local resolver, which will most likely use the router, or ISPs DNS server, and so forth.

thats also something a firewall cant protect you against.

The difference is that NAT doesn't track the counter party, so after you reached out to the DNS, any other service can use the opened port to connect to your PC.

With a stateful firewall, it tracks that the port was opened only used for the DNS server. If a connection to that port from a different IP address than the DNS server is made, the firewall will block it.

That is inside-out. It requires a client inside your network to initiate a connection to the outside. Obviously, NAT does nothing for preventing outbound connections.

The whole point-to-point connection between 2 NATed PCs isn't so much about security either. If an attacker wants to connect to your PC behind a NAT, all the attacker needs is to be routable.

If your router is only NATing packets and routing them, your PC is routable. The router will simply translate the addresses as usual. There is a good chance most people have never seen such a setup, as the router almost always includes other features like a stateful firewall. The firewall may even take advantage of the NAT information when it decides if a packet should be routed or dropped.

All NAT does is rewrite the Source Address and/or Destination Address fields in the IP header, and possibly the Source/Destination Port fields in the UDP or TCP header. There are many rewriting methods, including some that are designed to route packets from the public network ("port forwarding", etc).

Ok, so below is how I understand NAT to make a PC effectively (with exceptions) unroutable.

As I figured it, if pc Bob is behind a NAT, there is not a public IP address that will route to Bob. The NAT box (lets call it a router) does have a public IP address. However, when a packet arrives at the router, and the destination port isn't mapped (by mapped I don't just mean manual port forwarding but also the actual NAT process) to some port on Bob, the packet will never reach Bob.

In order to figure out a destination port that will even reach Bob at all, you either need to somehow get a recognized request from Bob, and look at the 'return address'. If you already have some control over Bob (or another PC in the NAT) that seems feasible, otherwise it takes a rather large dragnet. My point being, unless you have info on the state of the router, anything behind it is effectively unroutable.

I'd be very interested to hear where I am wrong, it's been a while since I covered this material.

You're still looking at NAT as used to masquerade the hosts on a LAN (often with RFC 1918 private addresses) so they appear as a single public internet address. That is actually one of the fancier uses of NAT, and it's almost always combined with a firewall/etc.

RFC 2663 defines[1] a "Basic NAT" as a one-to-one mapping of IP addresses. This can be useful as a way to combine two separate IP networks that share addresses. If you have two networks using the 10.1.x.y range, you could connect them with a Basic NAT so they each see the opposite network as addresses in the 10.2.x.y range.

NAT is just about the Address Translation. Routing is a separate feature, and dropping packets is a separate feature that can be left out, even if those are rare situations.

> but also the actual NAT process

Often you don't even need the NAT process to be involved. Send a packet to a NAT route with the internal destination address, and some routers will simply route the packet directly. Enabling the Source Routing options can also force packets to a specific host by guessing the local address, which is easy when everybody uses 192.168.1.x or other private addresses behind their NAT. Fortunately, this generally isn't possible anymore because LSRR is now usually dropped at the firewall.

If NAT sounds like a mess, it is. NAT is a shameless subversion of the "end-to-end principle, which has set network software development back decades.

[1] https://tools.ietf.org/html/rfc2663#section-4.1.1

Thanks for the info. Seems like I was indeed somewhat misinformed.

Learn something new every day.

Reply on news.ycombinator.com