Networking with NATs and Firewalls

Two weeks ago I talked a little bit about how Network Address Translators (NATs) work, but only hinted at the broader picture. There's a two step process for getting from those technical details to how you should deal with NATs and firewalls in WCF. Today's article covers a more general view of what NATs and firewalls are. Next week, I'll present the rollup article that incorporates all of these details so far and gives advice for using WCF. You'll have a head start on the article next week because it will include the material you're reading today as an introduction.

How NATs Affect Communication

Network address translation was created to enable 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 correlate return traffic with the original communication. Many home users now have an IP address that is only privately routable and rely on a NAT to provide global routing of packets.

A NAT does not provide a security boundary. However, common NAT configurations prevent the internal machines from being directly addressed. This both protects the internal machines from some unwanted connections and makes it difficult to write server applications that need to asynchronously send data back to the client. The NAT rewrites the addresses in packets to make it seem like connections are originating at the NAT machine. This causes the server to fail when it attempts to open a connection back to the client. If the server uses the client's perceived address, it will fail because the client address is not publicly routable. If the server uses the NAT's address, it will fail to connect because no application is listening on that machine.

Some NATs support the configuration of forwarding rules to allow external machines to connect to a particular internal machine. The instructions for configuring forwarding rules varies between different NATs and asking end users to change their NAT configuration is not recommended for most applications. Many end users either cannot or do not want to change their NAT configuration for a particular application.

How Firewalls Affect Communication

A firewall is a software or hardware device that applies rules to the traffic passing through to decide whether to allow or deny passage. Firewalls can be configured to examine incoming, outgoing, or both streams of traffic. The firewall provides a security boundary for the network at either the edge of the network or on the endpoint host. Business users have traditionally kept their servers behind a firewall to prevent malicious attacks. Since the introduction of the personal firewall in Windows XP Service Pack 2, the number of home users behind a firewall has greatly increased as well. This makes it very likely that one or both ends of a connection will have a firewall examining packets.

Firewalls vary greatly in terms of their complexity and capability for examining packets. Simple firewalls apply rules based on the source and destination addresses and ports in packets. Intelligent firewalls can also examine the contents of packets to make decisions. These firewalls come in many different configuration and are often used for specialized applications.

A common configuration for a home user firewall is to prohibit incoming connections unless an outgoing connection was made to that machine previously. A common configuration for a business user firewall is to prohibit incoming connections on all ports except a group specifically identified. An example is a firewall that prohibits connections on all ports except for ports 80 and 443 to provide HTTP and HTTPS service. Managed firewalls exist for both home and business users that permit a trusted user or process on the machine to change the firewall configuration. Managed firewalls are more common for home users where there is not a corporate policy controlling network usage.

Next time: Building a Custom File Transport, Part 6: Channel Factory

Comments

• Anonymous
  April 25, 2006
  I've pulled out the actual mechanics of the file transport into a separate class in this example.  Both...