netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Basic Routing
Date: Sun, 02 Nov 2008 14:51:43 -0600	[thread overview]
Message-ID: <490E12DF.6090602@riverviewtech.net> (raw)
In-Reply-To: <490DF4CA.1010808@amfes.com>

Note:  Because of the length of my reply I'm going to split this reply 
in to two parts.  The first (previous) part will be on routing in 
general and the second (this) part will be on NATing.

On 11/2/2008 12:43 PM, Daniel L. Miller wrote:
> I guess part of my difficulty lies in a lack of experience configuring 
> non-linux routers.  Behind-the-scenes, as it were, do all/most routers 
> use NAT to accomplish the goal of linking networks?  It always seemed to 
> me NAT was a 'kludge' that was somehow unnecessary when "more 
> expensive?" equipment was involved.

No, routers in general do *NOT* use NAT.

In all the above scenarios, all systems in the path see the real source 
and destination IPs of host 1 and host 2.  NAT is a way to change source 
and or destination address for some reason.

To understand NATing you need to understand that there are some IP 
address ranges that are *NOT* suppose to be seen on the global internet 
and thus have to be changed (translated) in to something that is more 
acceptable on the global internet.  Similar is also done with in complex 
networks, especially when tyeing multiple businesses together for some 
reason.

Usually the reason is that most networks use RFC 1918 Addresses reserved 
for Private Internets, which are *NOT* suppose to be on the open 
globally routable internet.  In fact, RFC 1918 addresses are typically 
filtered out as soon as they hit the internet, or at least the ISP 
/should/ filter them and not pass them.

Despite the fact that routing can handle these addresses with out any 
problem there are agreed upon rules / guidelines that have been agreed 
to that impose that these (RFC 1918) addresses are not to be in use on 
the internet.

Thus to allow systems that are on these RFC 1918 private IP addresses to 
reach the internet, their source address IP /Network Address/ has to be 
changed or /Translated/, thus we have /Network Address Translation/, or 
NAT for short.

Let's consider this very simple scenario where I have my home network 
and a router and a simple ADSL internet connection.

    :
    |
+--+--+         +----+
| RTR +---(A)---+ Me |
+-----+         +----+

Let's suppose I have a source IP of 192.168.1.2 and I want to search the 
web using Google, so my computer talks to 74.125.95.99 (one of the IPs 
that www.google.com resolves to).

My packet with a source IP address of 192.168.1.2 and a destination 
address of 74.125.95.99 leaves my computer and goes to my router 
(because of my /Default Gateway/).

My router then sees that it has to send the packet to its /Default 
Gateway/, my ISP's router.  However my router knows that it has to 
/Translate/ the source IP of the packet to something that is internet 
friendly.  So, my router alters the source IP of the packet to its own 
external globally routable IP address A.B.C.D, which is not an RFC 1918 
private IP address.  So now the packet with a source IP address of 
A.B.C.D and a destination address of 74.125.95.99 leaves my router and 
goes to my ISP's router.

My ISP's router chooses one of its upstream connections and sends the 
packet with a source IP address of A.B.C.D and a destination address of 
74.125.95.99 to one of its upstream router.  My ISP's upstream router 
will then choose a route and send the packet with a source IP address of 
A.B.C.D and a destination address of 74.125.95.99 on down the line until 
it reaches the destination 74.125.95.99.

Google will then process my packet and reply back to me.  Thus Google 
sends a packet with a source ip of 74.125.95.99 and a destination 
address of A.B.C.D back through the internet to my ISP's ISP, and my 
ISP, and to my router.

My router will then see the packet with a source ip of 74.125.95.99 and 
a destination address of A.B.C.D and realize that it is actually a reply 
packet that needs to be un/Translated/.  So my router will change the 
destination IP address of A.B.C.D back to my real IP address of 
192.168.1.2 and send it on to my computer.

My computer sees the packet with a source IP address of 74.125.95.99 and 
a destination address of 192.168.1.2 and realizes that it is the reply 
to the packet I sent moments earlier and hands it up through the network 
stack to my web browser.

As you can see the only place that /Network Address Translation/ (a.k.a. 
NAT) took place is where my private network connected to the global 
internet.

I had to use NAT because there are rules on the global internet that say 
that the IP addresses that I chose to use are not allowed on the global 
internet.  Recalling the previous diagram(s) where Bob and Tom connected 
their networks, they /could/ have /chosen/ to use NAT if they did not 
want to have to set up routes between each other.

Another use of NATing is to allow two completely independent networks to 
inter operate.  Below is an example of double NATing that I like to 
refer to as a "Customer Interface Router", typically used when a 
business is subscribing to a service and / or support form a larger 
entity that supports multiple individual customers all with varying and 
possibly conflicting network configurations.  An example of which might 
be a big wholesale book distributor or local / state / national 
government agency that is offering some sort of service to the small 
entity that has the Customer Interface Router (a.k.a. CIR).  Typically 
in such scenarios both entities only want to allow connections for the 
services needed with out having to re-configure their network to support 
connections to far flung parts of the others network, or in the case of 
the larger provider deal with potential overlapping IP address spaces of 
smaller networks.

    :
    |
+--+--+         +---+
| RTR +---(A)---+ T |
+-----+    |    +---+
            |
            |    +-----+
            +----+ CIR += = =
                 +-----+

So in this case, the Customer send a packet with a source IP of T and a 
destination IP address of CIR from their terminal T to the Customer 
Interface Router CIR.

The Customer Interface Router will then /Translate/ the source IP 
address to be it's own IP of the interface facing the providers network 
as well as /Translating/ the destination IP to be what ever the provider 
wants with in their own network.  Ultimately the Customer Interface 
Router sends a packet with a source IP of <IP of CIR's provider 
interface> and a destination IP address of <something with in the 
providers network>.

The packet will then pass through the providers network to the real end 
point equipment (AS/400, mainframe, video surveillance system, what 
ever) and be processed and a reply packet will be sent.

The reply packet with a source IP of <something with in the providers 
network> and a destination IP address of <IP of CIR's provider interface>.

The Customer Interface Router will receive the packet with a source IP 
of <something with in the providers network> and a destination IP 
address of <IP of CIR's provider interface> and /Translate/ the source 
IP address of CIR on the customers network as well as /Translating/ the 
destination IP to be T.  Ultimately the Customer Interface Router sends 
a packet with a source IP address of CIR and a destination IP address of 
CIR back to the terminal T.

Thus through the use of double NAT on the Customer Interface Router we 
have allowed two completely separate and independent network structures 
to communicate and inter operate with out any regard as to what the 
others network structure is.

In short, NATing is used when you need to cross two conceptually unique 
networks that do not necessarily play well with each other.



Grant. . . .

  parent reply	other threads:[~2008-11-02 20:51 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-02 16:15 Basic Routing Daniel L. Miller
2008-11-02 17:03 ` Rob Sterenborg
2008-11-02 18:43   ` Daniel L. Miller
2008-11-02 19:53     ` Rob Sterenborg
2008-11-03  1:59       ` Daniel L. Miller
2008-11-02 20:04     ` Grant Taylor
2008-11-02 20:51     ` Grant Taylor [this message]
2008-11-03  1:52       ` Daniel L. Miller
2008-11-03  2:34         ` Grant Taylor
2008-11-03 19:29           ` Daniel L. Miller
2008-11-03 19:39             ` Daniel L. Miller
2008-11-03 20:26               ` Grant Taylor
2008-11-05  0:00                 ` Daniel L. Miller
2008-11-05  5:21                   ` Rob Sterenborg
2008-11-05 15:56                     ` Grant Taylor
2008-11-05 18:22                       ` Rob Sterenborg
2008-11-05 18:30                         ` Grant Taylor
2008-11-05 19:49                           ` Rob Sterenborg
2008-11-05 15:24                   ` Grant Taylor
2008-11-03 23:40               ` Amos Jeffries
2008-11-04 23:13             ` Grant Taylor
2008-11-04 23:53               ` Daniel L. Miller
2008-11-05 12:24                 ` John Haxby
2008-11-05 17:31                   ` Grant Taylor
2010-09-20 21:40                     ` Daniel L. Miller
2010-09-20 23:41                       ` Jan Engelhardt
2010-09-21  3:34                       ` Grant Taylor
2008-11-05 17:17                 ` Grant Taylor
2008-11-02 19:06   ` Grant Taylor
2008-11-03 10:54     ` Pascal Hambourg
2008-11-03 16:35       ` Grant Taylor
  -- strict thread matches above, loose matches on Subject: below --
2014-10-04  1:10 Basic routing John Smithee
2014-10-04  1:24 ` John Smithee
2014-10-04  8:50   ` George Botye
2014-10-04  1:34 ` Neal Murphy
2014-10-04  2:52   ` John Smithee
2014-10-04  3:05     ` Dennis Jacobfeuerborn
2014-10-04  5:02     ` Neal Murphy
2014-10-04  7:04     ` John Lister
2014-10-04 11:06       ` John Smithee
2014-10-04 13:56         ` Thomas Bätzler
2014-10-04 15:07           ` John Smithee
2014-10-04 17:44             ` John Smithee
2014-10-05 15:41               ` John Lister
2014-10-06  9:41               ` André Paulsberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=490E12DF.6090602@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).