How Network Address Translation (NAT) Works
Statistics indicate that you likely would not be able to read this post without the help of network address translation. NATs are a mechanism for several machines to share a single external IP address. A port-remapping NAT maps an internal IP address and port for a connection to an external IP address with a new port number. The new port number allows the NAT to identify return traffic and route that back to the original machine. Many machines now have an IP address that is only privately routable and rely on a NAT to map them to a globally routable IP address.
Going through a NAT doesn't actually provide a security boundary for your computer although people sometimes speak of NATs as if they do. There are many NAT configurations that explicitly prevent unwanted connections to your internal machines, but that isn't an inherent requirement of being a NAT. Let's talk about the NATs that do remove direct addressability of the internal machines though, as that configuration is generally what gives networking applications the most grief.
When you remove direct addressability, it is no longer easy for a server to open a connection back to the client or for multiple clients to talk with each other in a peer-to-peer configuration. Here's a look at a basic NAT scenario:
The NAT is going to be rewriting the source and destination ports and addresses in the IP and TCP headers. This makes it look to the remote machine like the connection is actually coming from the NAT. If the server then tries to open a connection back to the NAT, the NAT has no idea what to do with the connection since it's not actually running the application that the server is trying to connect to. Some NATs allow you to configure a static port forwarding rule to solve this problem. When an external machine attempts to connect to the NAT on a particular port, the NAT can route this connection to the specified internal machine.
WCF has a variety of methods on both the client and server for working through NATs. I'll write up a post in a few weeks detailing what your options are. In the mean time, I've got a lot of WCF channel extensibility articles that I want to get out.
Next time: Configuring HTTP
Comments
- Anonymous
April 13, 2006
Yesterday, we looked at the tax you pay for a typical network stack. Where does all that tax go? Well,... - Anonymous
April 13, 2006
I know you said you would address the NAT stuff in more detail later (as pertaining to Indigo), but could you give me some hints on how to get started on this--in terms of doing it?
Thanks- - Anonymous
April 14, 2006
The best quick advice I can give is to carefully consider the transport and channel shape when building an application that has to go through a NAT/firewall on the client or server end. You have to avoid:
1) trying to connect to a non-addresable machine
2) trying to connect to a blocked port
3) losing messages with no way to detect errors
Basic HTTP is actually a good choice most of the time in this situation, unless the server is behind a NAT. Then, you have to use something like duplex TCP+Teredo. I believe Teredo support requires you to use a custom binding since it's only on the binding element.
You'd want to avoid dual and one-way bindings for the most part. - Anonymous
April 17, 2006
The AppDev: Something You Should Know is a great blog to read/subscribe to, it has loads of useful... - Anonymous
April 26, 2006
Two weeks ago I talked a little bit about how Network Address Translators (NATs) work, but only hinted...