Sunday, July 21, 2013

Accessing devices remotely. NAT/Port Forwarding


So you want to remotely access a server or computer that’s residing on your local network, there are quite a few ways to reach this goal. From remote access applications such as: logmein, teamviewer, to VPN access. What I’d like to emphasize is that if you are going to setup a device to be accessible both internally and externally that device must reside in the DMZ.

With that in mind let’s start by building our network and outlining the general actions as we move alone.
DMZ: it stands for demilitarized zone, it’s also known as the Perimeter. In other words, it’s the segment of your network that hosts publicly accessible servers/computer through the internet and accessible through your internal network as well.

Let’s look at the diagram as we move along.

We have basic network setup. There’s firewall with two interfaces, one of the interface is configured for the DMZ or perimeter and the other interface is configured for the LAN. 



Let’s say that the LAN segment is a 192.168.20.0/24 and the DMZ segment is a 172.16.10.0/16. Hosts in the LAN segment are able to communicate among each other and so are hosts in the DMZ, however they are not able to communicate between segments yet.

As you can the LAN and DMZ are complete different subnets therefore a “router” needs to be configured to direct traffic from one segment to the other. The routing function in our example is going be performed by the firewall; usually firewalls designed for small and medium sized businesses also include other services such as routing, vpn, dhcp, dns, web content filtering, etc.

The steps to configure the firewall settings will vary from vendor to vendor but the concept behind its functionality is the same.

Keep this is mind: your firewall isn’t a router, the firewall has routing functionality. This what you need to focus on: find the routing section of your router where you can add routes to allow traffic from one segment to the other. Many firewalls will do this for you automatically by updating the routing table every time you create a new segment, once you have verified that both segments are able to communicate you need to decide the type of traffic you’ll allow to between the DMZ and your LAN.

This is where you need to take what I call: a methodical process because you’ll be opening a public door into your network. When I configure firewalls I follow the basic principle of: everything is denied unless it’s explicitly allowed, that gives me a granular control which will allow me to control what type of traffic flows between segments.

As an administrator you’ll need to create the firewall rules to allow traffic from the internet to the DMZ, and from your LAN to DMZ and vice versa. Remember the principle: everything is denied unless it’s explicitly allowed.

So let’s see how process occurs: I’m hosting my own web server that’s being accessed by Local users to make changes to our in house application.  One of my internal users accessing the server has an IP address of 192.168.20.5, my Web server in the DMZ has an IP of 172.16.10.10. As described previously routing between these segments is working and I configured the firewall rules to allow traffic between the two segments.

Now, you might ask yourself this question: How do external users access my web server residing in my internal network? 



I can either use Network Address Translation (NAT) or I could use Port Forwarding for the external users to access the web server.

NAT, in its basic form is simple masquerading an internal IP address behind a public address. So let’s says we were assigned a public IP address of 1.2.3.4 which is assigned to the WAN interface of the firewall.



When my users go the public network (internet) they’ll be seen as coming from IP address 1.2.3.4. (There’s a NAT PAT process in the background that makes this magic happens.)

When a remote user attempts to connect to 1.2.3.4 IP address over port 80 the user will be hitting the firewall’s WAN interface, that’s not where you want to go. So the Firewall administrator needs to configure a firewall object that’s going to represent the Web server and assign it a public IP address to it.

So in this case the web server has a private IP address (configured on the physical interface) and a Public IP address that’s been logically configured in the firewall rules and settings. Let’s say that the other public IP address in our block is 1.2.3.5,( in this case your ISP provided you with multiple public IP addresses)  as the firewall administrator I create a firewall object for my web server and assigned the public IP address in the NAT section of it.

Now that I have this configuration in place, when users decide to go to www.jdtechsolutions.net to learn more about the network, information security, and technical services I provide in New York City area, DNS resolution is going to point them to 1.2.3.5 IP address (keep in mind I omitted explaining how DNS registration and how it works, to learn more about it check my DNS document).

When the connection arrives to our firewall it understand that there’s a NAT rule which will send traffic to the webserver based on our natting rule.



Port Forwarding: For it to make sense you need to have a basic understanding of tcp/ip so summarizing everything this is what happens:

Network applications such as HTTP, DNS, FTP use transport protocols for communication. TCP and UDP are the transport protocols in charge of allowing the flow of data, each application has corresponding  port number assigned to it  by design, for instance HTTP is TCP port 80, RDP is TCP port 3389 ( for a complete list visit iana.org web site or http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) so the information travels from one host to another the port representing the application number comes along with it, when it reaches the receiving end it presents itself with the port number. In a port forwarding process the firewall is configured in a way that when it receives traffic with a specific port number it understand that the traffic must be forwarded or directed to another host based on the firewall port forwarding rules.

Let’s do an example based on our network. Let’s say the users want to get to my web site ww.jdtechsolutions.net that’s being hosted in my local network.

The process to configure port forwarding is pretty simple and straight forward:
Configure the Port forwarding setting in your firewall, in our case we are going to forward traffic coming on TCP port 80 (HTTP) to our internal webserver IP address of 172.16.10.10.



So when traffic from a remote user to our website reaches the firewall, it automatically forwarding that traffic to the web server based on forwarding rules.

Let’s do another example, let’s say you’d like to access your Windows desktop computer from any location outside your network. You’d have to take the following steps:
  • Enable RDP on your local PC
  • Make sure your internal pc’s IP address remains the same by either setting a static IP or a reservation in your DHCP server.
  • Know the public IP address (keep in mind it might change if you have a dynamic IP, you can circumvent this either requesting a static IP from you ISP or registering with a service such as dyndns.org)
  • Create the port forwarding rule in your firewall. Forward TCP port 3389 to your internal IP.


That should cover it all, now every firewall is different but the concept behind what you need to do is the same. The following is an example of port forwarding in a Sonicwall firewall.


Remote Desktop Connection from a remote network to your office PC



Now, if you are new to this concepts you realized by now that there are many missed steps along the way. I didn't plan on doing a step by step process on how things work but rather a general overview of how port forwarding and NAT work. I’m sure that with this information, your technical intuition and the firewall documentation you’ll be able to fill in the holes I left out empty.

Feel free to drop us notes with questions or suggestions about this or any other of our published documents. You can also contact us for IT consulting services in the New York metropolitan area at info@jdtechsolutions.net or calling us at 646-500-0032.

No comments:

Post a Comment