FTPS (FTP over SSL) vs. SFTP (SSH File Transfer Protocol): what to choose

File transfer over the network using FTP protocol (defined by RFC 959 and later additions) takes roots in year 1980, when the first RFC for FTP protocol was published. FTP provides functions to upload, download and delete files, create and delete directories, read directory contents. While FTP is very popular, it has certain disadvantages that make it harder to use. The major drawbacks are lack of the uniform format for directory listing (this problem has been partially solved by introducing MLST command, but it\u2019s not supported by some servers) and presence of the secondary connection (DATA connection). Security in FTP is provided by employing SSL/TLS protocol for channel encryption as defined in RFC 2228. The secured version of FTP is called FTPS.

In UNIX systems another security standard has grown. It was SSH family of protocols. The primary function of SSH was to secure remote shell access to UNIX systems. Later SSH was extended with file transfer protocol \u2013 first SCP (in SSH 1.x), then SFTP (in SSH2). Version 1 of the SSH protocol is outdated, insecure and generally not recommended for use. Consequently SCP is not used anymore and SFTP gains popularity day by day.

\u201cSFTP\u201d abbreviation is often mistakenly used to specify some kind of Secure FTP, by which people most often mean FTPS. Another (similar) mistake is that SFTP is thought to be some kind of FTP over SSL. In fact SFTP is an abbreviation of \u201cSSH File Transfer Protocol\u201d. This is not FTP over SSL and not FTP over SSH (which is also technically possible, but very rare).

SFTP is a binary protocol, the latest version of which is standardized in RFC 4253. All commands (requests) are packed to binary messages and sent to the server, which replies with binary reply packets. In later versions SFTP has been extended to provide not just file upload/download operations, but also some file-system operations, such as file lock, symbolic link creation etc.

Both FTPS and SFTP use a combination of asymmetric algorithm (RSA, DSA), symmetric algorithm (DES/3DES, AES, Twhofish etc.) and a key-exchange algorithm. For authentication FTPS (or, to be more precise, SSL/TLS protocol under FTP) uses X.509 certificates, while SFTP (SSH protocol) uses SSH keys.

X.509 certificates include the public key and certain information about the certificate owner. This information lets the other side verify the integrity of the certificate itself and authenticity of the certificate owner. Verification can be done both by computer and to some extent by the human. X.509 certificate has an associated private key, which is usually stored separately from the certificate for security reasons.

SSH key contains only a public key (the associated private key is stored separately). It doesn\u2019t contain any information about the owner of the key. Neither it contains information that lets one reliably validate the integrity and authenticity. Some SSH software implementations use X.509 certificates for authentication, but in fact they don\u2019t validate the whole certificate chain \u2013 only the public key is used (which makes such authentication incomplete and similar to SSH key authentication).

Here\u2019s the brief list of Pros and Cons of the two protocols:

FTPS

Pros:

    * Widely known and used
    * The communication can be read and understood by the human
    * Provides services for server-to-server file transfer
    * SSL/TLS has good authentication mechanisms (X.509 certificate features)
    * FTP and SSL/TLS support is built into many internet communication frameworks.

Cons:

    * Doesn\u2019t have a uniform directory listing format
    * Requires a secondary DATA channel, which makes it hard to use behind the firewalls
    * Doesn\u2019t define a standard for file name character sets (encodings)
    * Not all FTP servers support SSL/TLS
    * Doesn\u2019t have a standard way to get and change file and directory attributes

SFTP

Pros:

    * Has good standards background which strictly defines most (if not all) aspects of operations
    * Has only one connection (no need for DATA connection)
    * The connection is always secured
    * The directory listing is uniform and machine-readable
    * The protocol includes operations for permission and attribute manipulation, file locking and more functionality

Cons:

    * The communication is binary and can\u2019t be logged \u201cas is\u201d for human reading
    * SSH keys are harder to manage and validate
    * The standards define certain things as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors.
    * No server-to-server copy and recursive directory removal operations
    * No built-in SSH/SFTP support in VCL and .NET frameworks

What to choose

As usually, the answer depends on what your goals and requirements are. In general, SFTP is technologically superior to FTPS. Of course, it\u2019s a good idea to implement support for both protocols, but they are different in concepts, in supported commands and in many other things.

It\u2019s a good idea to use FTPS when you have a server that needs to be accessed from personal devices (smartphones, PDAs etc.) or from some specific operating systems which have FTP support but don\u2019t have SSH / SFTP clients. If you are building a custom security solution, SFTP is probably the better option.

As for the client side, the requirements are defined by the server(s) that you plan to connect to. When connecting to Internet servers, SFTP is more popular because it\u2019s supported by Linux and UNIX servers by default.

For private host-to-host transfer you can use both SFTP and FTPS. For FTPS you would need to search for a free FTPS client and server software or purchase a license for commercial one. For SFTP support you can install OpenSSH package, which provides free client and server software. For commercial use we recommend Bitvise SSH server.

Please refer to https://www.eldos.com/security/articles/4672.php?page=all

Understanding Key Differences Between FTP, FTPS and SFTP

Perhaps the most common protocols used in file transfer today are FTP, FTPS and SFTP.  While the acronyms for these protocols are similar,  there are some key differences among them, in particular how data are exchanged, the level of security provided and firewall considerations.  Learning these key differences can help you when choosing a file transfer protocol or troubleshooting common connection issues.
FTP

The FTP (File Transfer Protocol) protocol has been around for quite some time.  It was first proposed in RFC 114 over 40 years ago and eventually evolved into RFC 959 which is the standard that FTP clients and servers follow today.

Data Exchange

The FTP protocol exchanges data using two separate channels known as the command channel and data channel.

The command channel typically runs on server port 21 and is responsible for accepting client connections and handling the exchange of simple commands between an FTP client and server.  The USER and PASS commands used for authenticating an FTP user are examples of commands that are exchanged on the command channel.  The command channel remains open until the client sends the QUIT command to disconnect, or the server forcibly disconnects the client due to inactivity or other reason.

The data channel, runs using on-demand temporary ports listening on the server (passive mode) or on the client (active mode) and is responsible for exchanging data in the form of directory listings and file transfers.  The LIST, STOR and RETR commands used for getting a server directory listing, uploading a file and downloading a file are examples of commands (sent using the command channel) that open a data channel.  Unlike the command channel which remains open during the entire FTP session, the data channel is closed once the transfer of data is complete.   In order to handle concurrent file transfers or directory listings a range of data channel ports must be used.

Security

Using FTP both the command and data channels are unencrypted.  Any data sent over these channels can be intercepted and read.

Firewall

Server -  Allow inbound connections on port 21.  Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range.  Consult your server documentation for instructions on how to set a passive port range.

Client - Allow outbound connections to port 21 and passive port range defined by server.
FTPS

When the FTP protocol was initially drafted security was not a concern.  Since then many things have changed and sending data over any public network without encryption is considered very risky and in some cases prohibited.  In order to address this issue a set of security extensions to the original FTP protocol were proposed in RFC 2228 that protect FTP data as it travels over the network using SSL encryption.

Data Exchange

See FTP

Security

Secure variants of FTP include FTPS Implicit SSL and FTPS Explicit SSL.  Both utilize SSL encryption.

FTPS Implicit SSL

In implicit SSL mode a required SSL session is established between client and server before any data is exchanged.  As it's name suggests, the use of SSL is implied and any connection attempt made by a client without using SSL are refused by the server.  FTPS implicit SSL services generally run on port 990.   Although still in use today, FTPS Implicit SSL is considered by many to be obsolete in favor of FTPS Explicit SSL.

FTPS Explicit SSL

In explicit SSL mode the client and server negotiate the level of protection used.  This is very useful in that the server can support both unencrypted FTP and encrypted FTPS sessions on a single port.  In an explicit SSL session the client first establishes an unencrypted connection to the FTP service.  Prior to sending user credentials, the client requests that the server switch the command channel to an SSL encrypted channel by sending the AUTH TLS or AUTH SSL command.  Upon successful setup of the SSL channel the client then sends user credentials to the FTP server.  These credentials along with any other commands sent to server during the FTP session are automatically encrypted by the SSL channel.  Similar to the way in which the command channel may be protected, the level of protection used on the data channel is negotiated between the client and server using the PROT command.

Firewall

Server -  Allow inbound connections on port 21 and / or 990.  Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range.  Consult your server documentation for instructions on how to set a passive port range.

Client - Allow outbound connections to port 21 and passive port range defined by server.
SFTP

SFTP is often confused with FTPS and vice-versa even though these protocols share nothing in common except their ability to securely transfer files.   SFTP is actually based on the SSH (Secure Shell) protocol which is best known for it's use in providing secure access to shell accounts on remote servers.

Data Exchange

Unlike FTP/S, SFTP does not utilize separate command and data channels.  Both data and commands are transferred in specially formatted packets via a single connection.

Security

All data sent between client and server is encrypted using an agreed upon encryption cipher.

Firewall

Server - Allow inbound connections on port 22.

Client - Allow outbound connections to port 22.
Share files via FTP, SFTP, or FTPS

JSCAPE MFT Server allows you to share files via FTP, SFTP, FTPS, and other file transfer protocols. This Managed File Transfer server runs on all popular platforms (including Windows, Linux, Unix, AIX, Solaris, and Mac OS/X) and now supports OpenID and SAML Single Sign On. Download a free evaluation edition now.

please refer to http://www.jscape.com/blog/bid/75602/Understanding-Key-Differences-Between-FTP-FTPS-and-SFTP

What is HTTPS - Why Secure a Web Site?

What is HTTPS?

HTTPS stands for HyperText Transfer Protocol over SSL (Secure Socket Layer). It is a TCP/IP protocol used by Web servers to transfer and display Web content securely. The data transferred is encrypted so that it cannot be read by anyone except the recipient.

HTTPS is used by any Web site that is collecting sensitive customer data such as banking information or purchasing information. If you are making a transaction online, you should make sure that it is done over HTTPS so that the data remains secure.

You can tell when a page is using HTTPS in two ways:

1. There will be a lock icon in the browser window pane (usually at the bottom).
2. The URL will say "https://"

Why use HTTPS?

If you're going to run an online store or ecommerce Web site, you should be aware of HTTPS - or HyperText Transfer Protocol with Secure Sockets Layer. HTTPS is a protocol to transfer encrypted data over the Web.

There are two primary differences between an HTTPS and an HTTP connection work:

• HTTPS connects on port 443, while HTTP is on port 80
• HTTPS encrypts the data sent and received with SSL, while HTTP sends it all as plain text

Most Web customers know that they should look for the https in the URL and the lock icon in their browser when they are making a transaction. So if your storefront is not using HTTPS, you will lose customers. But even still, it is common to find Web sites that collect money including credit card data over a plain HTTP connection. This is very bad.

As I said above, HTTP sends the data collected over the Internet in plain text. This means that if you have a form asking for a credit card number, that credit card number can be intercepted by anyone with a packet sniffer. Since there are many free sniffer software tools, this could be anyone at all. By collecting credit card information over an HTTP (not HTTPS) connection, you are broadcasting that credit card information to the world. And the only way your customer will learn it was stolen is when it's maxed out by a thief.

What You Need to Host Secure Pages

There are only a couple things you need in order to host secure pages on your Web site:

• A Web server such as Apache with mod_ssl that supports SSL encryption
• A Unique IP address - this is what the certificate providers use to validate the secure certificate
• An SSL Certificate from an SSL certificate provider

If you aren't sure about the first two items, you should contact your Web hosting provider. They will be able to tell you if you can use HTTPS on your Web site.

After You've Got Your HTTPS Certificate

Your hosting provider will need to set up the certificate in your Web server so that every time a page is accessed via the https:// protocol, it hits the secure server. Once that is set up, you can start building your Web pages that need to be secure.

Here are some tips for using HTTPS:

• Point to all Web forms on the https:// server. Whenever you link to Web forms on your Web site, get in the habit of linking to them with the full server URL including the https:// designation. This will insure that they always are secured.
• Use relative paths to images on secured pages. If you use a full path (http://www...) for your images, and those images are not on the secure server, your customers will get error messages that say things like: "Insecure data found. Continue?" This can be disconcerting, and many people will stop the purchase process when they see that. If you use relative paths, your images will be loaded from the same secure server as the rest of the page.
• Secure only the pages that request and collect data. It is possible to run your entire Web site on https://, but it slows down the connection and some SSL providers charge you on the bandwidth secured. You should only secure those pages that collect data.

NAT example

http://etutorials.org/Networking/Check+Point+FireWall/Chapter+10.+Network+Address+Translation/Limitations+of+NAT/

NAT overload

INTRODUCTION

NAT Overload is the most common NAT method used throughout all networks that connect to the Internet. This is because of the way it functions and the limitations it can overcome, and we'll explore all of these in the next two pages.

Whether you use a router, firewall appliance, Microsoft's Internet sharing ability or any 3rd party program that enables all your home computers to connect to the Internet via one connection, you're using NAT Overload.

This NAT mode is also know by other names, like NAPT (Network Address Port Translation), IP Masquerading and NAT with PAT (Port Address Translation). The different names logically come from the way NAT Overload works, and you'll understand this by the time we're finished with the topic.

NOTE: You should be familiar with TCP/IP & UDP communications, as well as how they use various Ports in order to identify the resources/applications they are trying to use. It's very important you understand them because NAT Overload is based on these Ports in order to identify sessions between hosts.

WHAT EXACTLY DOES NAT OVERLOAD DO ?

NAT Overload is a mix of Static & Dynamic NAT with a few enhancements thrown in (PAT- Port Address Translation) to make it work the way we need. By now you understand how both Static & Dynamic NAT work so we won't get into the details again. NAT Overload takes a Static or Dynamic IP Address that is bound to the public interface of the gateway (this could be a PC, router or firewall appliance) and allows all PCs within the private network to access the Internet.

If you find yourself wondering how this is possible with one only IP Address, you will be happy to find that the answer lies within PAT.

The diagram below shows you how a single session is handled by a NAT Overload enabled device:

So we have a host on a private network, its IP Address is 192.168.0.1 and it's sending a packet to the Internet, more specifically to IP Address 200.0.0.1, which we're assuming is a server. The Port, which is 23, tells us that it's trying to telnet to 200.0.0.1, since this is the default port telnet uses.

As the original packet passes through the router, the Source IP Address field is changed by the router from 192.168.0.1 to 203.31.218.100. However, notice that the ports are not changed.

The reason the Source IP Address is changed is obvious: The router's public IP Address must be placed in the Source IP Address field of the packet so the server we're trying to telnet to knows where the request is coming from so it can then send the reply.

That takes care of making sure the packet from the server we're telneting to finds its way back to the router's public interface. From there, the router needs to know which host on the private network it must send the reply to. For this, it uses the ports and we will be looking at that closer very soon.

Some might think that this example is pretty much the way a Static NAT router would behave, and if you're thinking just that you're totally right! In order to understand how a NAT Overload enabled router is different from Static NAT, we must add at least one more host in the private network, which we'll do right now.

With two or more hosts on the private network, in Static NAT mode we would require the equivalent number of public IP Addresses, right ? One for each private host, because Static NAT maps one public IP Address to each private host.

NAT Overload overcomes this limitation by using one public IP Address for all private hosts, but utilising the thousands of ports available in order to identify each private host's session.

UNLEASHING THE TRUE POWER OF NAT OVERLOAD

To help cover all possibilities and questions that might come up from these examples, we're going to add another two private hosts in our internal network. We'll assume that:

1) The 2nd host in our private network is trying to telnet to the same server as the 1st host

2) The 3rd host in our private network is trying to telnet to a different server on the Internet

So let's see how our example network looks:

Host 1 and 2 are telneting to the same server (203.31.218.100), the only difference between the two packets is their Source Port Numbers, the router uses these to keep track of which packet belongs to each host.

Let's examine what happens when Host 1's reply arrives:

A packet arrives on our router's public interface and is accepted. The packet's details are examined and show that it came from IP Address 200.0.0.1 Port 23 with a destination of 203.31.218.100 Port 3000. The router remembers that Host 1 and 2 just sent a packet to this IP Address and now, in order to determine to whom this response belongs, it carefully examines its Destination Port.

It focuses on the Destination Port because in any reply, the Destination Port takes the value of the initial packet's Source Port. This means that this packet is a reply to one sent previously to IP Address 200.0.0.1 with Source Port 3000. The router refers to its NAT table and finds a matching entry for the described initial packet. It recognises that the reply is intended for Host 1 and will forward it to the host.

The server to which Host 1 and 2 of our example private network are telneting uses the same logic to distinguish between the two separate sessions.

Because this can also be a bit difficult to imagine, I've included a diagram which shows the server receiving Host 1's initial packet and then sending a reply:

The example on this page is intended to show you the idea behind NAT Overload and how it works. We saw our little NAT Overload enabled router doing wonders with one single public IP Address. If we wanted to use Static or Dynamic NAT in this same example, we would definitely require 3 public IP Addresses for our 3 private hosts but thanks to NAT Overload, we only need one IP Address.

HOW NAT TRANSLATIONS TAKE PLACE

When covering Dynamic and Static NAT, we saw that it was either the Source or Destination IP Address that had to be modified by the NAT device. No matter which mode was used, the Source and Destination ports were never altered in any way.

NAT Overload on the other hand will use a single public IP Address for the routing process and change, in most cases, the Source or Destination port depending on whether it's an incoming or outgoing packet.

In the next diagram we have two computers that have each sent a packet out to the Internet and are expecting a reply. We take a look at how the router deals with these packets individually and where the information required to identify the expected replies is stored:

You've got to agree that that's a very simple setup. To make life easy, I haven't included any additional information about the generated packets because we'll deal with them individually.

So it's time to take a look at how the router deals with this first packet which belongs to Workstation 1:

The packet Workstation 1 generated arrives at the router's private interface which has IP Address 192.168.0.1. The router accepts the packet and processes it. Once inside the router, the packet's Source IP Address, Destination IP Address, Source Port and Destination Port are examined and the router decides that this is a valid packet so it should be forwarded to the Internet.

NAT is now about to take place (check NAT Table in the above diagram). The router will replace the Source IP Address (192.168.0.5) with its Public IP Address (200.0.0.1) and keep the rest of the information intact.

Note that in most cases, the Source Port is not changed unless it has already been used by a previous packet from the private network but, since this is the first outgoing packet, this cannot be the case.

Here's how the packet looked once it exited the router's public interface:

Time to check our second packet that will traverse the router, which is generated by Workstation 2 (the router has not yet received the reply to Workstation 1's packet).

We're going to assume that Workstation 2 uses the same Source Port (2400) as Workstation 1's packet, so you can see how the router will react:

This packet is a very good example to show you how great NAT Overload is because the router will need to 'do' something to make sure it's able to successfully receive the reply.

Let's look at what happens within the router as the packet arrives at its private interface:

As you can see, our second packet arrives at the router's private interface. It enters the router and since the packet is valid (it's not corrupt and contains a valid Destination IP Address in its IP Header) it's routed to the public interface and NAT is performed while a new entry is added into the router's NAT Table.

Looking at the NAT entries, you will notice that both first and second packets have the same Source Port, which is 2400. Since the router already used port 2400 as a Source Port for the first packet's NAT Translation and hasn't yet received a reply, it cannot use it again for the second packet. If it did use it, when a reply for any of the two packets came back the router wouldn't be able to distinguish whose it was.

For this reason, the router assigns a new Source Port for the second packet (14500), ensuring that the reply will get to the internal host for which it is intended:

Usually most NAT Overload enabled devices will assign Source Ports in the range of 1025 to 65500.

Keep in mind that when one host sends a packet to another, the Source Port it used in the packet will be substituted for the Destination Port in the reply packet.

For example, Host A sends a packet to Host B and this packet has a Source Port of 200, then when Host B replies to Host A its packet will have a Destination Port of 200. This way, Host A knows this is a reply to the initial packet it sent.

This is why it's important for the router to keep close track of Source Ports on outgoing packets and Destination Ports in all incoming packets.

FINAL NOTES

NAT Overload will work perfectly no matter which type of IP Address assignment you have. Whether it's Dynamic IP or Static, via dial up or a permanent connection, it makes no difference to the NAT device. You can now see how this particular NAT mode has helped preserve real (public) IP Addresses, because no matter how many internal hosts any private network has, it only requires one real IP Address in order to allow all internal hosts to access the Internet.

Now you have a good idea why NAT is such a popular topic, simply cause it's made such a big difference ion how networks connect to the Internet.

DYNAMIC NAT

Dynamic NAT is the second NAT mode we're going to talk about. Dynamic NAT, like Static NAT, is not that common in smaller networks but you'll find it used within larger corporations with complex networks.

The way Dynamic NAT differentiates from Static NAT is that where Static NAT provides a one-to-one internal to public static IP mapping, Dynamic NAT does the same but without making the mapping to the public IP static and usually uses a group of available public IPs.

WHAT EXACTLY DOES DYNAMIC NAT DO?

While looking at Static NAT, we understood that for every private IP Address that needs access to the Internet we would require one static public IP Address. This public IP Address is mapped to our internal host's IP Address and it is then able to communicate with the rest of the world.

With Dynamic NAT, we also map our internal IP Addresses to real public IP Addresses, but the mapping is not static, meaning that for each session our internal hosts communicate with the Internet, their public IP Addresses remain the same, but are likely to change. These IPs are taken from a pool of public IP Addresses that have been reserved by our ISP for our public network.

With Dynamic NAT, translations don't exist in the NAT table until the router receives traffic that requires translation. Dynamic translations have a timeout period after which they are purged from the translation table, thus making them available for other internal hosts.

The diagram below illustrates the way Dynamic NAT works:

The diagram above is our example network and shows our router, which is configured to perform Dynamic NAT for the network. We requested 4 public IPs from our ISP (203.31.218.210 to 203.31.218.213), which will be dynamically mapped by our router to our internal hosts. In this particular session our workstation, with IP Address 192.168.0.1, sends a request to the Internet and is assigned the public IP address 203.31.218.210. This mapping between the workstation's private and public IP Address will remain until the session finishes.

The router is configured with a special NAT timeout and, after this timeout is reached (no traffic sent/received during that time), the router will expire the particular mapping and reuse it for a different internal host.

Let's say that around noon, the users of workstations with IP Address 192.168.0.1 and 192.168.0.3 go to lunch, so they log off and leave their PCs on (even if they switched them off, it wouldn't make a difference unless they had some program running that was constantly generating Internet traffic because the NAT timeout would never be reached). While these users went out for lunch, the user on the workstation with IP Address 192.168.0.2 decided to stay and do some extra work on the Internet. After 1 hour, the users return and log back on, launch their web browser and start to search on the net.

The router, as expected, deleted the old mappings once the NAT timeout had been reached for each mapping and created new ones once the users launched their web browsers, because that action generated traffic to the Internet and therefore had to transit the router.

Here's how the new mappings look:

By now, I would like to believe that you have understood what Dynamic NAT is all about and roughly how it works.

BUT WHERE WOULD DYNAMIC NAT BE USED?

Again, everyone's network needs are different, though I must admit that finding a practical implementation for Dynamic NAT is perhaps more difficult than any other NAT mode :)

Come to think of it, I can't recall ever being required to implement Dynamic NAT for a customer or my own network, but that doesn't mean it's not used. There are some network setups in which Dynamic NAT would work perfectly and that's what i'm about to show you.

DYNAMIC NAT CONFIGURATION FOR CISCO ROUTER

Our Cisco Technical Knowledgebase contains detailed step-by-step instructions how to setup Dynamic NAT on a Cisco router. Please refer to our Dynamic NAT Configuration for Cisco Routers to read up more on its configuration.

IMPLEMENTATION OF DYNAMIC NAT

This example is about a company called 'Dynasoft'. Dynasoft deals with the development of high quality software applications. As a large software firm, it has multiple contractors that help complete special sections of the software it sells.

Because of the nature of this production model, Dynasoft requires its contractors to have a permanent link into its private development network, so the source code of all ongoing projects is available to all contractors:

Now because Dynasoft is concerned about its network security, it purchased a firewall that was configured to regulate each contractor's access within the development network.

For the rest of this example, we will concentrate on Dynasoft's and Datapro's (green) networks:

Dynasoft has configured its firewall only to allow a particular part of Datapro's internal network to access the servers and that is network192.168.50.0/24, which is Datapro's main development network.

This setup has been working fine, but Datapro is expanding its development network, so a second separate network (192.168.100.0/24)was created that also needs access to Dynasoft's development network. All hosts on this new network will be using the new DHCP server, which means that they'll have a dynamic IP Address.

In order for the new network to access Dynasoft's network, we need to somehow trick Dynasoft's Firewall into thinking that any workstation from the new network is actually part of the 192.168.50.0 network, that way it won't be denied access.

There was a suggestion to use Static NAT but there are a few problems:

a) All workstations are on DHCP, so Static NAT will not work properly since it requires the internal hosts in the new network to have static IP Addresses.

b) Datapro's administrator wants maximum security for this new network therefore having dynamic IPs makes it more difficult for someone to track a particular host from it by using its IP Address.

So, after taking all this into consideration it was decided to implement Dynamic NAT and here's what the solution looks like:

A Dynamic NAT router in this situation would do the job just fine. We would place the router between the existing (192.168.50.0) and new (192.168.100.0) network. Because of the way Dynamic NAT works, we would need to reserve a few IP Addresses from the 192.168.50.0network in order to allow the Dynamic NAT router to use them for mapping hosts on the new network - to the existing network. This way, no matter which IP Address any host in the new network has, Dynasoft's Firewall device will think it's part of the 192.168.50.0 network !

We should also point out that the number of IP Addresses we'd need to reserve from network 192.168.50.0 would depend on how many simultaneous connections we want to allow from network 192.168.100.0 to Dynasoft's development network.

For example, if we required 25 workstations from network 192.168.100.0 to have simultaneous connection to Dynasoft we'd need to reserve at least 25 IP Addresses from the 192.168.50.0 network.

As previously explained, the reserved IP Addresses will be used to map hosts coming from the 192.168.100.0 network and must not be used by any host or workstation within the 192.168.50.0 network. If any were used in this way it would cause IP conflicts between the host in the 192.168.50.0 network and the Dynamic NAT router that's mapping that particular IP Address to the host from the 192.168.100.0network.

So a good practice would be to set aside the last 30 IP Addresses from the 192.168.50.0 network, which would be 192.168.50.224 to192.168.50.254, and ensure no one is assigned any IP Address within that range.

All this assumes networks 192.168.50.0 and 192.168.100.0 are using a Class C default subnetmask (255.255.255.0).

On this page, you need to understand why we're going to introduce the Dynamic NAT router, how it will solve the problem (by mapping hosts on the new network to the existing one) and the requirements for the implementation of this solution (to reserve the required IP addreess from the existing network).

HOW NAT TRANSLATIONS TAKE PLACE

Most of the rules that apply for Static NAT (which we've already covered), also apply for Dynamic NAT and there are very few changes between the two, making it very easy to understand and digest :)

The actual process remains the same no matter which device we use, e.g Firewall appliance, Linux gateway, router etc.

Because we don't want to get confused by using a different example, we'll stick to the previous page's network between Dynasoft and its contractor - Datapro, but we're now focusing on Datapro's internal network to learn how the router between its two internal networks (192.168.50.0 and 192.168.100.0) will deal with the Dynamic NAT required in order for the new network to gain access to Dynasoft's development network:

Even though the diagram explains everything, we are just going to point out a few important things about the Dynamic NAT router. It's very important that you understand that the IP Addresses in the router's Pool are reserved addresses from the 192.168.50.0 network - this means that no device or host on that network, apart from the router itself, is allowed to use them.

The dynamic mapping that is created will be in place only for that particular session, meaning that once the workstation in the new network finishes its work on the Dynasoft network, or doesn't send any packets across the Dynamic NAT router within a given time period, then the router will clear the dynamic mapping and make the IP Address available to the next host or workstation that needs it.

The timeout period is different for each transport protocol (TCP/UDP) and NAT device. The ability to modify these timeouts depends entirely on the NAT device being used. As always, the RFCs give some guidelines for these values but not all vendors follow them :) You will find more interesting information about this subject in the NAT advanced section.

So, after getting all that out of the way, it's now time to have a closer look at the packets as they traverse the router to either network:

After it is determined that this packet must traverse the router, an IP Address is picked from the available pool that will be used to map IP Address 192.168.100.5. These entries are then stored within the router's RAM (NAT Table). As you can see, the Source, Destination ports and Destination IP are never modified on outgoing packets.

The router will then send the packet on to the 192.168.50.0 network and after a few milliseconds it receives the reply that our workstation on network 192.168.100.0 is waiting for:

The router finds an entry within its NAT mapping table (don't forget this table is stored in the router's RAM) and replaces destination IP192.168.50.200 with destination IP 192.168.100.5 and then forwards the packet to the new network. The Source, Destination ports and Source IP are not modified.

In case you're wondering why the ports have changed in comparison to the original outgoing packet, this is not because of NAT but the way IP communications work and happens to be way out of the scope of this page.

One important small detail I should bring to your attention is how the packet reply managed to arrive at the router's interface, which is on the existing network. You should know that to the existing Datapro network, the router is like a host with multiple IP Addresses.

I explained how the router maps IP Addresses on the existing network to the new network, but if someone on the existing network tried to send an ARP request for 192.168.50.200, then the router would immediately answer with its own MAC address. This is done to ensure that all traffic intended for workstations on the new network finds its way there. The same principle would apply no matter which NAT mode we used.

To sum up all the above while trying to keep things simple, because sometimes no matter how much you analyse a diagram it can still confuse you, the next diagram is a summary of how the packets are modified as they traverse a Dynamic NAT device which, in our example, is a router:

It's very easy to see that the Source IP Address (192.168.100.5) is changed as the packet traverses the Dynamic NAT router to arrive at Datapro's exist network and then move on to Dynasoft's network, whereas the reply from Dynasoft's network will enter Datapro's existing network and traverse the Dynamic NAT router and have its Destination IP Address modified to 192.168.100.5, thus reaching the workstation its intended to.

Believe it or not, we've come to the end of this page, next page talks about NAT Overload, which is also known as Network Address Port Translation, Port Address Translation or IP Masquerade in the Linux/Unix world.

STATIC NAT

Static NAT (also called inbound mapping) is the first mode we're going to talk about and also happens to be the most uncommon between smaller networks.

Static NAT was mainly created to allow hosts on your private network to be direcly accessible via the Internet using real public IPs; we'll see in great detail how this works and is maintained. Static NAT is also considered a bit dangerous because a misconfiguration to your firewall or other NAT-enabled device can result in the full exposure of the machine on your private network to which the public IP Address maps, and we'll see the security risks later on this page.

WHAT EXACTLY DOES STATIC NAT DO ?

As mentioned in the introduction, Static NAT allows the mapping of public IP Addresses to hosts inside the internal network. In simple english, this means you can have a computer on your private network that exists on the Internet with its own real IP.

The diagram below has been designed to help you understand exactly how Static NAT works:

 

In this diagram you can see that we have our private network connected to the Internet via our router, which has been configured for Static NAT mode. In this mode each private host has a single public IP Address mapped to it, e.g private host 192.168.0.1 has the public IP Address 203.31.218.208 mapped to it. Therefore any packets generated by 192.168.0.1 that need to be routed to the Internet will have their source IP field replaced with IP Address 203.31.218.208.

All IP translations take place within the router's memory and the whole process is totally transparent to both internal and external hosts. When hosts from the Internet try to contact the internal hosts, their packets will either be dropped or forwarded to the internal hosts depending on the router's & firewall configuration.

BUT WHERE WOULD STATIC NAT BE USED?

Everyone's needs are different and with this in mind Static NAT could be the solution for many companies that require a host on their internal network to be visible and accessible from the Internet.

Let's take a close look at a few examples of places where Static NAT could be used.

IMPLEMENTATION OF STATIC NAT - EXAMPLE 1

We have a development server (192.168.0.20) that needs to be secure, but also allow certain customers to gain access to various services it offers for development purposes. At the same time, we need to give the customers access to a special database located on our main file server (192.168.0.10):

In this case, Static NAT, with a set of complex filters to make sure only authorised IP Addresses get through, would do the job just fine.

Also, if you wanted a similar setup for the purpose of using only one service, e.g http, then you're better off using a different NAT mode simply because it offers better security and is more restrictive.

Let me remind you that Static NAT requires one public IP Address for each mapping to a private IP Address. This means that you're not able to map a public IP Address to more than one private IP Address.

IMPLEMENTATION OF STATIC NAT - EXAMPLE 2

Another good example of using Static NAT is in a DMZ zone. The principle of having a DMZ zone is when you require certain machines e.g webservers, email servers, to be directly accessible to the Internet but at the same time, should these machines be compromised, all data can be restored without much trouble and they won't expose the internal private network to the Internet.

The diagram above might seem very complex, but it's actually extremely simple. Breaking it down will help you see how simple it is. If we focus on Firewall No.1 we see that it's connected to 3 networks, first one is the Internet (203.31.218.X), second one the DMZ(192.168.100.X) and the third is the small private network between our two Firewalls (192.168.200.X)

Firewall No.1 is configured to use Static NAT for 3 different hosts - that's two from the DMZ zone and one for Firewall No.2. Each interface of the Firewall must be part of a different network in order to route traffic between them. This explains why we have so many different IP Addresses in the diagram, resulting in the complex appearance.

With this setup in mind, the Static NAT table of Firewall No.1 would look like this:

Firewall No.1 Static NAT Table
External Public IP Address	Mapped to Internal Private IP Address
203.31.218.2	Firewall No.1 Public Interface
203.31.218.3	192.168.100.2 - Public WebServer in DMZ
203.31.218.4	192.168.100.3 - Public MailServer in DMZ
203.31.218.5	192.168.200.2 - Firewall No.2 of Private Net.

As you can see, this table is a good summary of what is happening in the diagram above. Each external IP Address is mapped to an internal private IP Address and if we want to restrict access to particular hosts then we can simply put an access policy (packet filters) on Firewall No.1.

HOW NAT TRANSLATIONS TAKE PLACE

So what exactly happens to the packet that enters or exits the Static NAT-enabled device ? Well it's not that complicated once you get the hang of it. The concept is simple and we're going to see it and analyse it using an example, which is really the best possible approach.

The process of the Static NAT translation is the same for every device that supports it (assuming the manufacturer has followed the RFCs). This means that whether we use a router or a firewall appliance to perform Static NAT they'll both follow the same guidelines.

Consider our example network:

As the diagram describes we have Workstation No.1, which sends a request to the Internet. Its gateway is the router that connects the LAN to the Internet and also performs Static NAT.

The diagram below shows us how the Workstation's packet is altered as it transits the router before it's sent to the Internet (outgoing packet):

As you can see, the only thing that changes is the Source IP, which was 192.168.0.3 and was given the value of 203.31.220.135, which is a real IP Address on the Internet. The Destination IP Address, Source Port and Destination Port are not modified.

Assuming the packet arrives at its destination, we would most likely expect to see a reply. It would be logical to assume that the reply, or incoming packet, will require some sort of modification in order to successfully arrive at the originating host located on our private network (that's Workstation 1).

Here is how the incoming packet is altered as it transits the router:

The diagram above shows the part of the incoming packet that is altered by the router. Only the destination IP Address is changed, from 203.31.220.135 to 192.168.0.3 so the packet can then be routed to the internal workstation. Source IP Address, Source Port and Destination Port remain the same.

And in case you're wondering why the ports have changed in comparison to the original outgoing packet, this is not because of NAT but the way IP communications work and happens to be way out of the scope of this topic.

Now, because I understand that even a simple diagram can be very confusing, here's one more that summarises all the above. The diagram below shows you what the outgoing and incoming packets looked like before and after transiting the router: