Basic Routing

Basic Routing

[Daniel L. Miller]

To act as a router, where a box has two NIC's, and is connecting a LAN 
with 192.168.0.0/24 to the Internet - is SNAT required?  Or can this be 
accomplished without NAT?

-- 
Daniel

RE: Basic Routing

[Rob Sterenborg]

> To act as a router, where a box has two NIC's, and is connecting a
> LAN with 192.168.0.0/24 to the Internet - is SNAT required?  Or can
> this be accomplished without NAT?

192.168.x.x is private space IP. You cannot route private space IP's on
the internet: you need NAT to give internet access to your clients (or a
proxy if you only need protocols for which proxies are available). This
can be done with SNAT, MASQUARADE (some people need this instead of
SNAT) and I've read somewhere it can also be done using "ip" but I'm not
familiar doing that.


Grts,
Rob

Re: Basic Routing

[Daniel L. Miller]

Rob Sterenborg wrote:
>> To act as a router, where a box has two NIC's, and is connecting a
>> LAN with 192.168.0.0/24 to the Internet - is SNAT required?  Or can
>> this be accomplished without NAT?
>>     
>
> 192.168.x.x is private space IP. You cannot route private space IP's on
> the internet: you need NAT to give internet access to your clients (or a
> proxy if you only need protocols for which proxies are available). This
> can be done with SNAT, MASQUARADE (some people need this instead of
> SNAT) and I've read somewhere it can also be done using "ip" but I'm not
> familiar doing that.
>   
Thanx.  I'm still not sure of the vocabulary with which to phrase my 
"true" question - so I'll try it with more words (although I think 
you've already answered me - I'm just looking for confirmation).

Given:
1.  A linux box "router" that has ip-fowarding enabled, and no 
restrictions via iptables.
2.  This box has a routing table that lists two or more networks

If another host on network 'A', lists the box "router" as its default 
gateway, and tries to contact network 'B' through the router - will the 
router automagically pass along the packets?  Or this simply doesn't 
work, because of a basic networking concept I haven't grasped - and NAT 
is the technique to accomplish this?

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.
-- 
Daniel

Re: Basic Routing

[Grant Taylor]

On 11/2/2008 11:03 AM, Rob Sterenborg wrote:
> 192.168.x.x is private space IP. You cannot route private space IP's 
> on the internet: you need NAT to give internet access to your clients 
> (or a proxy if you only need protocols for which proxies are 
> available). This can be done with SNAT, MASQUARADE (some people need 
> this instead of SNAT) and I've read somewhere it can also be done 
> using "ip" but I'm not familiar doing that.

You have to have some form of NAT for the aforementioned reason. 
However it is possible to do this on a layer 2 device via EBTables / 
IPTables with bridged netfilter traffic enabled.

It is my (mis)understanding that Cisco PIX /Firewalls/ (All /PIX/es are 
firewalls NOT routers) do the ""routing with the layer 2 NATing and thus 
appearing as routers.

In essence from L2 you watch for any traffic coming from the L3 IP 
address space in question and then NAT the L3 addresses with (on L2) to 
be the actual L3 address you want to appear as.  The same thing happens 
in reverse and you tend to have what appears to be a L3 ""router, but in 
actuality it's purely an L2 device pretending to be / doing the function 
of an L3 router.

(Though at this point it is debatable what it actually is.  I choose to 
say it's an L2 device b/c it operates on L2 and looks to higher layers 
in the stack where as normal L3 routers operate on L3 and /may/ look 
down if at all.)

IPTables uses what is considered /stateful/ NAT.  Remember when IPTables 
introduced connection tracking and the state match extension in 2.4 
years ago?  Previously IPChains did not have such state.  The (older ?) 
installs of the IP (ip) command could do /stateless/ NAT.  I say older 
because I'm not sure that the stateless NAT provided by IP exists any 
more. ... (checking) ...  According to the IP man page, stateless NAT is 
no longer supported:  "Warning: Route NAT is no longer supported in 
Linux 2.6."



Grant. . . .

RE: Basic Routing

[Rob Sterenborg]

> Thanx.  I'm still not sure of the vocabulary with which to phrase
> my "true" question - so I'll try it with more words (although I
> think you've already answered me - I'm just looking for
> confirmation).
> 
> Given:
> 1.  A linux box "router" that has ip-fowarding enabled, and no
> restrictions via iptables.
> 2.  This box has a routing table that lists two or more networks
> 
> If another host on network 'A', lists the box "router" as its
> default gateway, and tries to contact network 'B' through the
> router - will the router automagically pass along the packets? 

If network A is your LAN and network B is "the internet", the packet
might be routed onto the internet but even if it reaches the destination
IP (which it may not because of the configuration of other routers and
firewalls), you'll never get a reply packet because a reply packet for a
private IP will most likely be routed to their own DMZ or LAN. So, you
can't setup a full connection like this.
However, if you were using public IP's (not in 192.168.x.x, etc) on your
LAN then you could just route the packet.

> Or this simply doesn't work, because of a basic networking concept
> I haven't grasped - and NAT is the technique to accomplish this?

Yes, one way or another, some form of NAT is the technique to be used.
As Grant explained you can also use ebtables. I'm writing about NAT
using iptables.

> 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? 

Normally you'd only encounter NAT situations when connecting a
host/network to the internet and you're using private space IP's on the
network.

> It always seemed to me NAT was a 'kludge' that was somehow
> unnecessary when "more expensive?" equipment was involved.

No, NAT is a necessary kludge because not every computer that must be
connected to the internet can have a public IP: there just aren't enough
IP's to do that. That's why home networks and corporate networks (well,
those I know of) mostly use private IP's on their LAN and use NAT
(and/or a proxy) to get to the internet.

NAT is not/should not be necessary between networks if you have
something like this:

-------------  -------  -------------
| Network A |--| RTR |--| Network B |
-------------  -------  -------------
 
Here, the router knows the route to each network and can just route
packets to each other. No need for NAT here.
 
Maybe you find this tutorial useful in understanding things. The history
says it's not updated since 2006, but the information still holds for at
least the large part.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html


Grts,
Rob

Re: Basic Routing

[Grant Taylor]

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

On 11/2/2008 12:43 PM, Daniel L. Miller wrote:
> Thanx.  I'm still not sure of the vocabulary with which to phrase my 
> "true" question - so I'll try it with more words (although I think 
> you've already answered me - I'm just looking for confirmation).

Eh...  What Daniel said is true, but your (mis)understandings are not 
quite right.  You are actually trying to understand some lower level 
functionality by observing some higher level functionality that causes 
you to misconstrue the underlying functionality.  It's sort of like 
trying to grab something under water while looking at it from out of the 
water if you don't know that water changes the angle you need to look at.

> Given:
> 1.  A linux box "router" that has ip-fowarding enabled, and no 
> restrictions via iptables.
> 2.  This box has a routing table that lists two or more networks
> 
> If another host on network 'A', lists the box "router" as its default 
> gateway, and tries to contact network 'B' through the router - will the 
> router automagically pass along the packets?  Or this simply doesn't 
> work, because of a basic networking concept I haven't grasped - and NAT 
> is the technique to accomplish this?

Yes and no.

NATing, or Network Address Translation, is a special technique to alter 
(possibly hide) either the source and / or destination address the 
traffic is coming from and / or going to.  (I say "and / or" because it 
is possible to NAT both the source and destination if need be, which is 
called double NATing and even more complex.)

First let's say that a /Default Gateway/ is nothing more than a catch 
all route to be used when there are no other better routes to use.  In 
essence, use the /Default Gateway/ as the last resort to fall back on if 
nothing else works.

Now, routes in general are just a way of saying that if you want to go 
to this particular destination, you need to go by way of here to get to 
your ultimate destination.

Now, let's consider your scenario above:

+---+         +--------+         +---+
| 1 +---(A)---+ Router +---(B)---+ 2 |
+---+         +--------+         +---+

We configure host 1 on network A to use the Router as its default 
gateway and similarly we configure host 2 to use the Router as its 
default gateway.

Now, host 1 can ping any thing on network A directly because it is local 
and with in it's (sub)net(work).  However if host 1 wants to ping any 
thing out side of network A it will have to find a route to get to the 
destination.  Knowing that host 1 only has one route, the /Default 
Gateway/ all traffic not going to the local (sub)net(work) will go to 
the /Default Gateway/.  So, host 1 sends its traffic to the /Default 
Gateway/ of Router.  Now it is up to Router to handle the traffic.

Router now has traffic from host 1 that it needs to deliver to host 2. 
So Router looks in its routing tables and finds that host 2 is in 
network B and that it is directly attached to network B and as such is 
able to send the traffic directly to host 2 in network B.

When host 2 receives the traffic and is ready to reply to host 1 it goes 
through a similar process as host 1 to send the reply traffic.  Likewise 
Router handles the traffic in reverse.

Thus hosts 1 and 2 are able to talk to each other by way of Router.

When hosts 1 and 2 are talking to each other, they both know that that 
traffic originated from the other because of the source IP address in 
the packets they received.

Now, let's elaborate the network connection a bit more to further 
explain routing.

                  :                 :
                  |                 |
+---+         +--+--+           +--+--+         +---+
| 1 +---(A)---+ Bob +===(XXX)===+ Tom +---(B)---+ 2 |
+---+         +-----+           +-----+         +---+

Here we have two friends that have their home network, each with their 
own internet connection.  However, considering that they are friends, 
they have some sort of connection between their homes to allow them to 
use each others network resources.  This connection could be a VPN 
across the internet, or it could be a wireless network connection, or if 
they are close enough to each other, it could be an ethernet connection 
between their routers.

In this scenario, both hosts 1 and 2 use their local routers (Bob and 
Tom respectively) as their /Default Gateway/.

Now let's re-consider host 1 pinging host 2 in this new network.  Like 
before, when host 1 wants to pint host 2 it finds that host 2 is not 
with in its network and thus must have a route to get there.  Like 
before host 1 will send the traffic to its /Default Gateway/ (in this 
case) "Bob".  Bob will then have to find a route to get to host 2.  This 
time Bob has a default gateway of the internet connection (going out the 
top) -AND- Bob has a route to network B by way of "Tom".  So Bob will 
send the packet on to Tom.  Tom will then as you would expect see that 
host 2 is directly connected to network B and send the packet on to host 2.

Similarly when host 2 replies, it's traffic will go to it's /Default 
Gateway/ (in this case) "Tom".  Tom will then find that it has a route 
to network A by way of "Bob" and as such will send traffic to network A 
to Bob.  Bob will then see that the traffic is to a system on network A 
and send the traffic accordingly.

In both of the above scenarios hosts 1 and 2 used the /Default Gateway/ 
to send their traffic and did not need a routing table with any thing 
more than their /Default Gateway/.  The following scenario is a bit 
different.

    :                                             :
    |                                             |
+--+--+         +---+           +---+         +--+--+
| Bob +---(A)---+ 1 |           | 2 +---(B)---+ Tom |
+-----+    |    +---+           +---+    |    +-----+
            |                             |
            |    +---+           +---+    |
            +----+ 7 +===(XXX)===+ 8 +----+
                 +---+           +---+

Here things are more than a bit different.  In this configuration, we 
still have Bob's and Tom's houses, except this time the connection 
between the two networks is not through their /Default Gateway/ but 
rather the respective systems 7 and 8.

In this scenario, when host 1 wants to ping host 2, host 1 will again 
consult its routing table.  However this time there will have to be an 
entry that says that network B is accessible by  host 7 in addition to 
the /Default Gateway/ entry.  Thus when host 1 sends its packet it will 
find that it needs to send the packet to host 7 rather than the /Default 
Gateway/ of "Bob".  Host 7 will then receive the packet and find that it 
needs to send the packet on to host 8.  Host 8 will then find that it 
can send the packet directly to host 2 on the local network B.

Similarly host 2 will have to have a route in its routing table so that 
it knows that it reaches network A by way of host 8.  Thus host 2 sends 
its reply packet to host 8 which sends the packet on to host 7 which 
then sends the packet directly to host 1.

> 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.

Quickly, *NO*, routers in general do *NOT* use NAT.  Look at my next 
email for an explanation as to what NAT is for.



Grant. . . .

Re: Basic Routing

[Grant Taylor]

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. . . .

Re: Basic Routing

[Daniel L. Miller]

Grant Taylor wrote:
> 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.
I'm going to read these two mails a few times - I sincerely appreciate 
the thorough answer - hopefully it'll penetrate my skull soon enough.

I do understand that the private address ranges were not to be directly 
exposed to the Internet.  I guess what I was looking for was for a 
router to perform the following:

1.  Host 'A' realizes Host 'B' is not on its network
2.  Host 'A' contacts Router 'C' and asks it to get the information out 
and bring back the response.
3.  Router 'C', via whatever magical method (DNS/hosts/etc.) figures out 
the router responsible for Host 'B's presence on the Internet.
4.  Router 'C' contacts Router 'D', sends along the information, and 
tells Router 'D' to send any responses to ROUTER C, not Host A
5.  D, goes to B, comes back to D, and back to C
6.  Router C, on receiving a response from D, remembers that Host 'A' 
was waiting for this information and sends it on.

In essence, I believe I'm correct in this summary - however the tool 
used by Router C for "remembering" that Host A asked for the 
information, and that responses from Router D should come back to Router 
C, is NAT?

So does this mean that ANY connection of a private address space to the 
Internet MUST be performed via NAT?
-- 
Daniel

Re: Basic Routing

[Daniel L. Miller]

Rob Sterenborg wrote:
> Maybe you find this tutorial useful in understanding things. The history
> says it's not updated since 2006, but the information still holds for at
> least the large part.
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html
>   
Thanks - I'll be reading through it.

-- 
Daniel

Re: Basic Routing

[Grant Taylor]

On 11/2/2008 7:52 PM, Daniel L. Miller wrote:
> I'm going to read these two mails a few times - I sincerely appreciate 
> the thorough answer - hopefully it'll penetrate my skull soon enough.

*nod*  You are welcome.  It's my way of giving back to the community 
that has given me so much.  :)

If you have any more questions, please reply, either to the mailing list 
or directly to me off list, which ever you prefer, and I'll do my best 
to answer.

> I do understand that the private address ranges were not to be directly 
> exposed to the Internet.  I guess what I was looking for was for a 
> router to perform the following:

*nod*

> 1.  Host 'A' realizes Host 'B' is not on its network

This is what the net mask and subnets are all about in the IP stack and 
has nothing to do with a router.  (Other than the fact the router has 
its own IP stack and (sub)net mask(s) too.)

> 2.  Host 'A' contacts Router 'C' and asks it to get the information out 
> and bring back the response.

(As long as you are not talking about any form of proxying...)

This is what routes are all about, with the /Default Gateway/ route 
being special in such as it is the one used when no other routes match.

> 3.  Router 'C', via whatever magical method (DNS/hosts/etc.) figures out 
> the router responsible for Host 'B's presence on the Internet.

Eh.  Now you are sounding more and more like a proxy.  Routers only pass 
IP packets based on routes.  Any DNS operation is the responsibility of 
the application that generated the packet that is now being routed by 
the router.

> 4.  Router 'C' contacts Router 'D', sends along the information, and 
> tells Router 'D' to send any responses to ROUTER C, not Host A

It's not so much that routers ""contact each other as it is that each 
router hands off the IP packet to the next router for it to route to the 
next and the next ... and you get the idea.  There is not really a 
request that something be done.

> 5.  D, goes to B, comes back to D, and back to C

You could be talking about IP packets flowing through networks or proxy 
requests flowing from clients to the proxy and ultimately to the 
destination server and back in reverse.

> 6.  Router C, on receiving a response from D, remembers that Host 'A' 
> was waiting for this information and sends it on.

This is is probably what you are thinking NAT does, which in some / most 
ways is correct.  However, the same can be said about a proxy.

> In essence, I believe I'm correct in this summary - however the tool 
> used by Router C for "remembering" that Host A asked for the 
> information, and that responses from Router D should come back to Router 
> C, is NAT?

Eh, not really.

I'm going to go out on a limb here and think that you are thinking of a 
network like this:

+---+
| B |
+-+-+
   :

   :
+-+-+       +---+
| C +---+---+ A |
+---+   |   +---+
         |
         |   +---+
         +---+ D |
             +---+

I believe this is the sequence of events you are trying to make happen:

  - Client A is trying to contact the server B by way of router C.
  - Router C intercepts the request and hands it off to system D.
  - System D then initiates the request to B by way of router C (and 
many other intermediary routers).
    (C does not intercept the request because it is from system D.)
  - Server B replies back to D by way of (many other intermediary 
routers and) router C.
  - System D then replies back to router C.
  - Router C then replies back to client A.

Is this close to what you are wanting to happen?  (Let me know before I 
explain how to make this happen.)

> So does this mean that ANY connection of a private address space to the 
> Internet MUST be performed via NAT?

Yes.  In the scenario above (presuming that my picture above matches 
what you have) Router C does NAT to convert the internal IP addresses 
used on the internal LAN to that of the internet side of Router C so 
that the packets will cross the internet.  Refer to the "Simple 
Scenario" in my previous reply about NATing.



Grant. . . .

Re: Basic Routing

[Pascal Hambourg]

Hello,

Grant Taylor a écrit :
> 
> You have to have some form of NAT for the aforementioned reason. However 
> it is possible to do this on a layer 2 device via EBTables / IPTables 
> with bridged netfilter traffic enabled.

Ebtables, are you sure ? AFAIK ebtables does only layer 2 MAC address 
translation, not IP address translation. Don't you mean bridge-nf aka 
bridge-netfilter instead of ebtables ?

> In essence from L2 you watch for any traffic coming from the L3 IP 
> address space in question and then NAT the L3 addresses with (on L2) to 
> be the actual L3 address you want to appear as.  The same thing happens 
> in reverse and you tend to have what appears to be a L3 ""router, but in 
> actuality it's purely an L2 device pretending to be / doing the function 
> of an L3 router.

It's far from being that simple. Doing stateful IP address translation 
at layer 2 requires other operations such as fragment reassembly because 
stateful NAT operates at the datagram level, not at the packet level, 
and rerouting and ARP lookup when the destination IP and MAC addresses 
change. IMO these are definitely not layer 2 operations.

> IPTables uses what is considered /stateful/ NAT.  Remember when IPTables 
> introduced connection tracking and the state match extension in 2.4 
> years ago?  Previously IPChains did not have such state.

Ipchains did not have a state match extension, but it had some 
connection tracking for its NAT features (masquerading and port forwarding).

> The (older ?) 
> installs of the IP (ip) command could do /stateless/ NAT.  I say older 
> because I'm not sure that the stateless NAT provided by IP exists any 
> more. ... (checking) ...  According to the IP man page, stateless NAT is 
> no longer supported:  "Warning: Route NAT is no longer supported in 
> Linux 2.6."

Actually the IP_ROUTE_NAT option enabling the old stateless NAT aka 
"fast NAT" or "route NAT" support in the kernel has been removed since 
kernel 2.6.9 only. But a new stateless NAT was added in kernel 2.6.24. 
See option NET_ACT_NAT in the "QoS and/or fair queueing" menu (yeah, I 
guess the location may seem misleading). I have not dug into it, but I 
think it can be set up with the "tc" tool from the iproute package. It 
requires iproute2-2.6.24-rc7 at least.

Re: Basic Routing

[Grant Taylor]

On 11/03/08 04:54, Pascal Hambourg wrote:
> Hello,

Hi.

> Ebtables, are you sure ? AFAIK ebtables does only layer 2 MAC address 
> translation, not IP address translation. Don't you mean bridge-nf aka 
> bridge-netfilter instead of ebtables ?

It's been too long so I can not say for 100% sure, but it may have been 
with bridge-nf.  However, even if you are using bridge-netfilter and 
using IPTables to operate on the layer 2 bridged traffic, this is still 
done on layer 2, not layer 3.  I know it's starting to get ambiguous, 
but...  I.e. I could have one subnet split in half and be NATing the 
traffic as it passes through, say .3 can automagically become .4.

> It's far from being that simple. Doing stateful IP address translation 
> at layer 2 requires other operations such as fragment reassembly because 
> stateful NAT operates at the datagram level, not at the packet level, 
> and rerouting and ARP lookup when the destination IP and MAC addresses 
> change. IMO these are definitely not layer 2 operations.

You have some good points about where NAT operates.  With out going back 
and reviewing my notes and old config, I believe it /is/ possible to do, 
just very much of a kludge and difficult to do.

> Ipchains did not have a state match extension, but it had some 
> connection tracking for its NAT features (masquerading and port 
> forwarding).

Could be that NAT had some connection tracking.  I did not really mess 
with IPChains that much, more IPTables, so I don't know for sure.

> Actually the IP_ROUTE_NAT option enabling the old stateless NAT aka 
> "fast NAT" or "route NAT" support in the kernel has been removed since 
> kernel 2.6.9 only. But a new stateless NAT was added in kernel 2.6.24. 
> See option NET_ACT_NAT in the "QoS and/or fair queueing" menu (yeah, I 
> guess the location may seem misleading). I have not dug into it, but I 
> think it can be set up with the "tc" tool from the iproute package. It 
> requires iproute2-2.6.24-rc7 at least.

*nod*

I may have to dig it out and look at it some time.  I'm glad to know 
that they brought something back that offered the stateless NAT 
functionality.



Grant. . . .

Re: Basic Routing

[Daniel L. Miller]

Grant Taylor wrote:
>> 1.  Host 'A' realizes Host 'B' is not on its network
>
> This is what the net mask and subnets are all about in the IP stack 
> and has nothing to do with a router.  (Other than the fact the router 
> has its own IP stack and (sub)net mask(s) too.)
*dumbly nodding*  Ok.
>
>> 2.  Host 'A' contacts Router 'C' and asks it to get the information 
>> out and bring back the response.
>
> (As long as you are not talking about any form of proxying...)
>
> This is what routes are all about, with the /Default Gateway/ route 
> being special in such as it is the one used when no other routes match.
*dumbly nodding - slight eye glazing*  Um....ok.
>
>> 3.  Router 'C', via whatever magical method (DNS/hosts/etc.) figures 
>> out the router responsible for Host 'B's presence on the Internet.
>
> Eh.  Now you are sounding more and more like a proxy.  Routers only 
> pass IP packets based on routes.  Any DNS operation is the 
> responsibility of the application that generated the packet that is 
> now being routed by the router.
*significant eye glazing - jaw slack*  Um...er...maybe...
Rephrase - "Router C checks it's list of routes, figures out it's 
clueless with regard to the route for Router D, and passes the buck to 
Router C's default gateway"
>
>> 4.  Router 'C' contacts Router 'D', sends along the information, and 
>> tells Router 'D' to send any responses to ROUTER C, not Host A
>
> It's not so much that routers ""contact each other as it is that each 
> router hands off the IP packet to the next router for it to route to 
> the next and the next ... and you get the idea.  There is not really a 
> request that something be done.
*Excitedly* - That's it!  That's the part we need to talk about!  Router 
"hands off the IP packet to the next router to the next to the next" -

Router C has a route table -
192.168.0.0/24 dev eth0
2.3.4.5 dev eth1
default gateway 2.3.4.4

Router 2.3.4.4 (premise equipment from mysterious ISP)
mysterious routing table

Router 5.4.3.1 (premise equipment from other ISP)
more mysterious routing table

Router D has a route table -
10.0.0.0/8 dev eth0
5.4.3.2 dev eth1
default gateway 5.4.3.1

Does the above communication involve NAT?  No "hosts" or private 
networks involved - all public IP's between them (unless of course the 
packets traverse private IP ranges within the ISPs' networks before 
coming back out.
>
>> 5.  D, goes to B, comes back to D, and back to C
>
> You could be talking about IP packets flowing through networks or 
> proxy requests flowing from clients to the proxy and ultimately to the 
> destination server and back in reverse.
*Sheepishly* Assume for sake of argument I'm expressing myself poorly - 
no proxies involved in this discussion.  That would make it too simple.
>
>> 6.  Router C, on receiving a response from D, remembers that Host 'A' 
>> was waiting for this information and sends it on.
>
> This is is probably what you are thinking NAT does, which in some / 
> most ways is correct.  However, the same can be said about a proxy.
*Assertively* No proxy.
>
>> In essence, I believe I'm correct in this summary - however the tool 
>> used by Router C for "remembering" that Host A asked for the 
>> information, and that responses from Router D should come back to 
>> Router C, is NAT?
>
> Eh, not really.
>
> I'm going to go out on a limb here and think that you are thinking of 
> a network like this:
>
> +---+
> | B |
> +-+-+
>   :
>
>   :
> +-+-+       +---+
> | C +---+---+ A |
> +---+   |   +---+
>         |
>         |   +---+
>         +---+ D |
>             +---+
>
> I believe this is the sequence of events you are trying to make happen:
>
>  - Client A is trying to contact the server B by way of router C.
>  - Router C intercepts the request and hands it off to system D.
>  - System D then initiates the request to B by way of router C (and 
> many other intermediary routers).
>    (C does not intercept the request because it is from system D.)
>  - Server B replies back to D by way of (many other intermediary 
> routers and) router C.
>  - System D then replies back to router C.
>  - Router C then replies back to client A.
>
> Is this close to what you are wanting to happen?  (Let me know before 
> I explain how to make this happen.)
>
Um...no.  Too complicated.

A==>C<==Internet==>D<===B

Two offices on opposite sides of the world linked via Internet.
>> So does this mean that ANY connection of a private address space to 
>> the Internet MUST be performed via NAT?
>
> Yes.  In the scenario above (presuming that my picture above matches 
> what you have) Router C does NAT to convert the internal IP addresses 
> used on the internal LAN to that of the internet side of Router C so 
> that the packets will cross the internet.  Refer to the "Simple 
> Scenario" in my previous reply about NATing.
>
So the world's most expensive super-duper whatchamacallit (fill in the 
blank here with router, firewall, bridge, modem, magic cauldron), placed 
between giant corporate's network (using private address space) and the 
Internet - will perform NAT?  Somewhere somehow NAT (in particular, 
source NAT for outbound access from the private and destination NAT to 
provide services to Internet) must be performed?
-- 
Daniel

Re: Basic Routing

[Daniel L. Miller]

Daniel L. Miller wrote:
> Grant Taylor wrote:
>> Is this close to what you are wanting to happen?  (Let me know before 
>> I explain how to make this happen.)
> Um...no.  Too complicated.
>
Now that we're discussing that - let's change gears and talk about it 
differently.
> A==>C<==>D<===B
No Internet - but still private networks.  So Router C has a route for 
the network 'A' 192.168.0.0/24 and route to reach router 'D'.  Router 
'D' knows about network 'B' 192.168.1.0 and router 'C'.  D and C talk to 
each other, just because, on their own network of 172.16.0.0/16.

Is any NAT required for this conversation?  In particular - do Linux 
routers require SNAT lines for this?  Or just routing tables?
-- 
Daniel

Re: Basic Routing

[Grant Taylor]

(Note:  I'll read and reply to your previous message later this evening 
when I have more time.)

On 11/03/08 13:39, Daniel L. Miller wrote:
> Now that we're discussing that - let's change gears and talk about it 
> differently.

Ok...

>> A==>C<==>D<===B

*nod*

> No Internet - but still private networks.  So Router C has a route for 
> the network 'A' 192.168.0.0/24 and route to reach router 'D'.  Router 
> 'D' knows about network 'B' 192.168.1.0 and router 'C'.  D and C talk to 
> each other, just because, on their own network of 172.16.0.0/16.

Correct.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

Thus we have three networks, x, y, and z.
x 192.168.0/24
y 172.16.0/16
z 192.168.1/24

A will have one IP address of x.A.
C will have two IP addresses of x.C and y.C.
D will have two IP addresses of y.D and z.D.
B will have one IP address of z.B.

A will have the following routes:
    x is directly attached
    y is reachable by way of x.C
    z is reachable by way of x.C

C will have the following routes:
    x is directly attached
    y is directly attached
    z is reachable by way of y.D

D will have the following routes:
    x is reachable by way of y.C
    y is directly attached
    z is directly attached

B will have the following routes:
    x is reachable by way of z.D
    y is reachable by way of z.D
    z id directly attached

In this scenario, none of the systems really have to have a default 
gateway at all.  However all of the systems will have to have one or two 
routes set up.  You /could/ use default gateways if you wanted to.  A 
and B would probably use C and D (respectively) as their defaults. 
However it is really up to you to decide what you want to be the 
defaults for C and D.

> Is any NAT required for this conversation?  In particular - do Linux 
> routers require SNAT lines for this?  Or just routing tables?

No.  NAT is not required.

Remember that NAT is a way to change addresses so that connections 
appear to be to and / or from a different address than they actually 
are.  You could do the above configuration with NAT, but it will 
actually make things more difficult.

If you were to use NAT, you would have to decide a few things.  What 
address do you want A and B to talk to.  Is A going to talk to z.B on a 
remote network or is it going to talk to x.C on its local network 
(similarly is B going to talk to x.A or z.D).  This determines if you 
will have to have any routing set up at all.

If you do not have routing set up, and choose to use NAT you will have 
to do a fair amount of NATing on all systems.  I.e. C will have to 
forward any traffic that comes in to x.C on to y.D.  Likewise D will 
have to forward any traffic that come sin to y.D on to z.B.  Similarly 
in reverse, D will have to forward any traffic that comes in to x.D on 
to y.C.  As you would expect C will have to forward any thing that come 
sin to y.C to x.A.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+
               |------------->                     x.C -> y.D
                             |------------->       y.D -> z.B
                   <-------------|                 z.D -> y.C
     <-------------|                               y.C -> x.A

As you can see this is fairly complex and could easily and quickly get 
WAY out of hand.  Where as with traditional routing things are much simpler.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+
     <--------->   <--------->   <--------->

As an added benefit of routing, any system can talk to any other system 
on any network (presuming nothing is put in place to stop it).  Where as 
with NATing, the only thing that A will be able to talk to remotely is B 
it self.  If you want A or B to talk to other systems on the respective 
remote networks, you will have to set up even more NATing.

So, no, you do not /have/ to have NAT.  But you /can/ use NAT if you 
have some specific reason for wanting to do it.  (Refer to my Customer 
Interface Router description in a previous email.)



Grant. . . .

Re: Basic Routing

[Amos Jeffries]

Daniel L. Miller wrote:
> Daniel L. Miller wrote:
>> Grant Taylor wrote:
>>> Is this close to what you are wanting to happen?  (Let me know before 
>>> I explain how to make this happen.)
>> Um...no.  Too complicated.
>>

Daniel,
   lets cut this right back to the basics and answer your original question:

   1) NAT is needed to change private IPs (192.168.0.0/16) to Internet 
IPs. It does not in itself send packets anywhere.

   2) everything else just uses straight routing.

   puddles of NAT around the rest of the internet are invisible and 
completely ignored by your systems.


> Now that we're discussing that - let's change gears and talk about it 
> differently.
>> A==>C<==>D<===B
> No Internet - but still private networks.  So Router C has a route for 
> the network 'A' 192.168.0.0/24 and route to reach router 'D'.  Router 
> 'D' knows about network 'B' 192.168.1.0 and router 'C'.  D and C talk to 
> each other, just because, on their own network of 172.16.0.0/16.
> 
> Is any NAT required for this conversation?  In particular - do Linux 
> routers require SNAT lines for this?  Or just routing tables?


NAT is different to routing. All it does is change the private IPs 
back-n-forth. plain old routing is still needed to get the private 
packets to the NAT place and then the public packets out across the 
Internet.

Lets follow that sequence:

  A creates a packet(A->D) and 'routes' it to C.
  C takes the packet(A->D). NATs it packet(C->D). then routes it to B
  B takes the packet(C->D). NATs it packet(B->D). then routes it to D.
  D takes the packet(B->D).


  D replies with packet(D->B).
  B takes the packet(D->B) and NATs it packet(D->C). then routes it to C.
  C takes the packet(D->C) and NATs it packet(D->A). then routes it to A.
  A gets reply packet(D->A)

Far too complicated than it needs to be yes?
So NAT only happens when one of the IPs needs to be changed (ie from a 
private IP to a 'public' one, or from one private to another private)

If you really have different 192.168.*.0/24 networks at A and B. AND 
also control the network C-D. You should be able to get away without NAT.
By simply setting the route table of C to route B network through D.
And D route table to route network A through C.


AYJ

Re: Basic Routing

[Grant Taylor]

(Now that I have time *AND* internet, DSL was out at the house last 
night... *GR!!!*)

On 11/03/08 13:29, Daniel L. Miller wrote:
> *dumbly nodding*  Ok.

Ok as in "Dough!" or ok as in "???"?

> *dumbly nodding - slight eye glazing*  Um....ok.

Remember that a system will decide where to hand the packet(s) off to 
(which router) by looking through its own routing table sequentially. 
The first route that is found that matches the destination that you are 
trying to reach is the route that is used to send the packet(s).

The /Default Gateway/ is a special route in such as it is the last 
resort at the end of the routing table.  So if no other routes (if there 
are any) match then the /Default Gateway/ route will match any 
destination, thus sending any packet(s) that did not match any other 
routes out through the /Default Gateway/.  Another way to think of the 
/Default Gateway/ is as a 'Catch All' route.

> *significant eye glazing - jaw slack*  Um...er...maybe...

(Are you having fun yet?)

> Rephrase - "Router C checks it's list of routes, figures out it's 
> clueless with regard to the route for Router D, and passes the buck to 
> Router C's default gateway"

Much closer.  Try this on for size.  "Router C checks it's list of 
routes, figures out it's clueless with regards to the route to host B, 
and passes the buck to Router C's default gateway."  (Remember that 
Router C knows how to reach Router D because they share the common 
connection.)


> *Excitedly* - That's it!  That's the part we need to talk about!  Router 
> "hands off the IP packet to the next router to the next to the next" -

Ok.  I think it's time for a quick segway in to how a packet(s) are 
passed around ethernet networks.

Remember that IP addresses /cross/ network boundaries and that MAC 
addresses are /confined/ with in network boundaries.  So we talk IP 
addresses across multiple different networks.  When two hosts with in 
the same network talk they really talk MAC address to MAC address.

Let's take your fairly simple diagram below.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

This is what the sequence of events will be for host A to send an IP 
packet to host B.

  - A sends an ethernet frame with a source MAC address of x.A and a 
destination MAC address of x.C, containing an IP packet with a source IP 
address of x.A and a destination IP address of z.B.
  - C sends an ethernet frame with a source MAC address of y.C and a 
destination MAC address of y.D, containing an IP packet with a source IP 
address of x.A and a destination IP address of z.B.
  - D sends an ethernet frame with a source MAC address of z.D and a 
destination MAC address of z.B, containing an IP packet with a source IP 
address of x.A and a destination IP address of z.B.

Notice how each pair of locally connected hosts (on the same network) 
talk to each other with their own MAC addresses to work together to pass 
the IP packet containing the actual message that is to be sent.

> Router C has a route table -
> 192.168.0.0/24 dev eth0
> 2.3.4.5 dev eth1
> default gateway 2.3.4.4
> 
> Router 2.3.4.4 (premise equipment from mysterious ISP)
> mysterious routing table
> 
> Router 5.4.3.1 (premise equipment from other ISP)
> more mysterious routing table
> 
> Router D has a route table -
> 10.0.0.0/8 dev eth0
> 5.4.3.2 dev eth1
> default gateway 5.4.3.1

Ok.  You just indicated that routers C and D are not directly connected 
to each other on the same ethernet network but rather are in different 
subnets, likely using different ISPs.  This complicates things a bit.

> Does the above communication involve NAT?  No "hosts" or private 
> networks involved - all public IP's between them (unless of course the 
> packets traverse private IP ranges within the ISPs' networks before 
> coming back out.

Possibly, at least for general internet access.  There will be NAT 
between the private LAN IP address space (192.168.0/24 and 10/8) and the 
internet.

That being said, if you establish a VPN between Router C and Router D 
across the internet (which I'm going to assume will be done), you can 
have LAN to LAN traffic with out NATing in between them.  This can 
happen because the VPN will encapsulate the traffic leaving the 
192.168.0/24 network going to the 10/8 network.  This encapsulation raps 
the packets and uses the globally routable IP address of Routers C and D 
as the source and destination IPs for the /VPN/ traffic.  When the VPN 
traffic reaches Router D, it will decapsulate it and send it out to the 
LAN on its end.

So, yes NAT is used to send normal traffic to the internet and no NAT is 
not used (VPN encapsulation is) to send LAN to LAN traffic.

> *Sheepishly* Assume for sake of argument I'm expressing myself poorly - 
> no proxies involved in this discussion.  That would make it too simple.

Ok.  I just had to double check, you understand why.  :)

> *Assertively* No proxy.

*nod*

> Um...no.  Too complicated.
> 
> A==>C<==Internet==>D<===B

(See my email from yesterday afternoon.)

> Two offices on opposite sides of the world linked via Internet.

*nod*

This means that you will most likely be dealing with VPNs

> So the world's most expensive super-duper whatchamacallit (fill in the 
> blank here with router, firewall, bridge, modem, magic cauldron), placed 
> between giant corporate's network (using private address space) and the 
> Internet - will perform NAT?  Somewhere somehow NAT (in particular, 
> source NAT for outbound access from the private and destination NAT to 
> provide services to Internet) must be performed?

Correct.  The word you are looking for is usually a router that does 
firewalling, or sometimes knows as a firewalling router.  (Remember that 
firewalls really /filter/ traffic while routers /route/ traffic, 
sometimes altering it along the way.)

Even IBM and Microsoft (presuming they are using private class IP 
address space) are either running NATing routers between their internal 
corporate networks.  (As an alternative they could be doing proxying, 
but it is most likely that they are using NAT.)



Grant. . . .

Re: Basic Routing

[Daniel L. Miller]

Grant Taylor wrote:
>> Does the above communication involve NAT?  No "hosts" or private 
>> networks involved - all public IP's between them (unless of course 
>> the packets traverse private IP ranges within the ISPs' networks 
>> before coming back out.
>
> Possibly, at least for general internet access.  There will be NAT 
> between the private LAN IP address space (192.168.0/24 and 10/8) and 
> the internet.
>
> That being said, if you establish a VPN between Router C and Router D 
> across the internet (which I'm going to assume will be done), you can 
> have LAN to LAN traffic with out NATing in between them.  This can 
> happen because the VPN will encapsulate the traffic leaving the 
> 192.168.0/24 network going to the 10/8 network.  This encapsulation 
> raps the packets and uses the globally routable IP address of Routers 
> C and D as the source and destination IPs for the /VPN/ traffic.  When 
> the VPN traffic reaches Router D, it will decapsulate it and send it 
> out to the LAN on its end.
>
> So, yes NAT is used to send normal traffic to the internet and no NAT 
> is not used (VPN encapsulation is) to send LAN to LAN traffic.
>
*Head bouncing on desk*  You just had to do it.  You just HAD to throw 
something else in, didn't you?  Ok - no VPN during these discussions!!!  
That's next thread.
>> Two offices on opposite sides of the world linked via Internet.
>
> *nod*
>
> This means that you will most likely be dealing with VPNs
Once again - I'm using language that's too ambiguous.  I actually 
probably inferred that - but I didn't intend to.  The INTENT was to 
illustrate a clumsy, inefficient, amateurish connection between Internet 
connected sites using non-VPN capable home-office consumer-grade 
firewall routers - the under $20 kind.

You're assuming a level of capability and courtesy for the sysadmin I am 
not - nor am I talking about higher-level protocols.  So from Los 
Angeles, they'll have to type in the public IP address of the New York 
router to reach that office.

*Exasperated shrug* Now that I've typed that - it really doesn't make 
too much sense.  All right - fine.  I guess a VPN was needed somewhere.  
But darn it - the VPN operates at a higher level - somewhere along the 
line the VPN server/router needs to translate the virtual IP's to 
something the rest of the world understands - and that means NAT!
>
>> So the world's most expensive super-duper whatchamacallit (fill in 
>> the blank here with router, firewall, bridge, modem, magic cauldron), 
>> placed between giant corporate's network (using private address 
>> space) and the Internet - will perform NAT?  Somewhere somehow NAT 
>> (in particular, source NAT for outbound access from the private and 
>> destination NAT to provide services to Internet) must be performed?
>
> Correct.  The word you are looking for is usually a router that does 
> firewalling, or sometimes knows as a firewalling router.  (Remember 
> that firewalls really /filter/ traffic while routers /route/ traffic, 
> sometimes altering it along the way.)
>
> Even IBM and Microsoft (presuming they are using private class IP 
> address space) are either running NATing routers between their 
> internal corporate networks.  (As an alternative they could be doing 
> proxying, but it is most likely that they are using NAT.)
Again with the proxy (what's the matter with you?  Trying to give me a 
complete answer that accounts for the exceptions?  Geez....)

I think my confusion stems from my own introduction to IP, which was via 
WindozeNT 4.0.  Somewhere along the line NAT was referred to in some 
documentation as a "poor-man's solution" to doing "proper" routing - and 
that concept has carried forward with me to where I keep thinking NAT is 
somehow an inferior solution to the "proper" way of doing things.  If 
the only "proper" (read: other) way of connecting LAN's to the Internet 
is by assigning public IP's to workstations (and of course 
purchasing/reserving/controlling such IP's) - then I can drop the 
inferiority complex I've held with regard to NAT.

-- 
Daniel L. Miller, VP - Engineering, SET
AM Fire & Electronic Services, Inc. [AMFES]
dmiller@amfes.com 702-312-5276

Re: Basic Routing

[Daniel L. Miller]

Grant Taylor wrote:
>> No Internet - but still private networks.  So Router C has a route 
>> for the network 'A' 192.168.0.0/24 and route to reach router 'D'.  
>> Router 'D' knows about network 'B' 192.168.1.0 and router 'C'.  D and 
>> C talk to each other, just because, on their own network of 
>> 172.16.0.0/16.
>> Is any NAT required for this conversation?  In particular - do Linux 
>> routers require SNAT lines for this?  Or just routing tables?
>
> No.  NAT is not required.

I guess here's a Linux specific question - as opposed to the more 
general IP/routing discussion we've been having.

Given a Linux box with multiple networks on one or more interfaces 
(192.168.0.1 on eth0, 192.168.5.1 on eth0:0, 172.26.0.1 on eth1, etc.) - 
and just adding a "1" to /proc/sys/net/ip_forward - will this magic box 
be able to forward packets between the networks without further 
configuration?  Or will this require NAT statements from iptables (and 
no, this is NOT an opportunity to tell me about 
ipchains/ebtables/other-Linux-networking-specialty-program-kernel-interface-I-didn't-mention)?

Ok fine - if you can recommend a tool to make this easier - I'd be 
delighted to hear about it.  Right now my configuration tool is firehol.
-- 
Daniel

RE: Basic Routing

[Rob Sterenborg]

Grant is doing too good a job... :-)

> I guess here's a Linux specific question - as opposed to the more
> general IP/routing discussion we've been having.
> 
> Given a Linux box with multiple networks on one or more interfaces
> (192.168.0.1 on eth0, 192.168.5.1 on eth0:0, 172.26.0.1 on eth1,
> etc.) - and just adding a "1" to /proc/sys/net/ip_forward - will
> this magic box be able to forward packets between the networks
> without further configuration? 

Since these IP's are all private you do NOT need NAT.
Do NOT use NAT in this situation unless you tried plain routing and for
some fancy reason, strange situation or requirement you find out you
might actually need NAT here. But in your case I don't think you will
come to that conclusion unless there's something you haven't told us yet
(again: I don't think so).
Just enable and allow all forwarding, add the routes you need and your
magic box will shine like a magic lantern. :^)

So, like:

iptables -P FORWARD ACCEPT
iptables -F FORWARD
echo 1 > /proc/sys/net/ipv4/ip_forward
route add -net [...etc...]

No, this is not secure, but that's not what we're talking about here.
This way, your box will effectively be a router. No fancy filtering,
NAT-ing, whatever.

> Or will this require NAT statements from iptables (and no, this is
> NOT an opportunity to tell me about ipchains/ebtables/other-Linux-
> networking-specialty-program-kernel- interface-I-didn't-mention)?

No, it will NOT.

> Ok fine - if you can recommend a tool to make this easier - I'd be
> delighted to hear about it.  Right now my configuration tool is
> firehol.

Have a look at http://www.fwbuilder.org/.
I'm not using it, I'm not endorsing it, don't know anything of how it
builds it's ruleset, etc. It just looks nice if you're coming from MS
ISA and you might actually find it handy.


Grts,
Rob

Re: Basic Routing

[John Haxby]

Daniel L. Miller wrote:
> *Head bouncing on desk*  You just had to do it.  You just HAD to throw 
> something else in, didn't you?  Ok - no VPN during these 
> discussions!!!  That's next thread.


Perhaps the problem is that the good people on this list know just too
much about the finer points of routing and the caveats and wrinkles that
you occasionally need to avoid special purpose problems.

For the most part, though, it's actually quite simple.   And I know that
some of the things I will say are wrong in some cases and I would hope
that someone will explain to me where they're wrong and maybe we'll all
be enlightened.

Anyway, routing first.   For a given machine it's pretty
straightforward.   You have an IP address to which you want to send a
packet (routing is per-packet, not per-connection).   Type "route -n"
and run your finger down the list of routes from top to bottom.   Use
the "genmask" to mask off the bits in the IP address that you have (that
is, "and" it -- eg an IP address of 192.168.2.5 and a genmask of
255.255.255.0 will give you 192.168.2.5).  If the result is the same as
the destination column then you send the packet to the gateway and
device indicated.

There are two special cases in the routing table: a gateway of 0.0.0.0
means "this machine" which means, basically, that you're on the same LAN
as the destination IP.   A destination of "0.0.0.0" (and similar mask)
is usually called the default route: if you take the conjunction ("and")
of any IP address and 0.0.0.0 you'll get 0.0.0.0 and so any address not
previously matched will go to the indicated gateway.

You may notice that the routing table is sorted by the number of zeroed
bits in the genmask column: 255.255.255.0 comes before 255.255.240.0
which comes before 255.255.0.0 and so 0.0.0.0 is always last.  That's
why you can run your finger down the routing table from top to bottom to
find where a packet will go and that, of course, is exactly what the
kernel does.

Most machines only have a single NIC and are connected to a single
network and have a default route so the routing table has only two
entries: the local LAN and the default route.   Machines with more than
one network device will have more routing entries -- you need at least
two network devices (real or virtual) to have any need for more complex
routing.

I slipped in "(real or virtual)" there for a reason.  When you set up a
VPN connection from home to the office then it is exactly as though you
have put an extra network card in your machine and run a very long cable
to the office.   You now have two network devices, one connected to the
local LAN and one connected to the office network and a routing table to
match.   Actually, there's one small difference between a virtual
private network and a real private network (apart from miles of cat-5
cable): there is a route with a genmask of 255.255.255.255 that is used
to route traffic to the machine at the other end of the vpn link.
Apart from that, think of a VPN has just another NIC that happens to be
called (usually) tun0 instead of eth1.


Right.  NAT.

NAT is completely different to routing.    In routing a packet is sent
to a gateway machine completely unmodified (apart from some housekeeping
things that you don't need to worry about right now).   NAT is different
because it modified the IP packets.   For most people, NAT modifies the
source IP address and port -- that means that when you're at home
surfing the net behind your Netgear firewall/router/ADSL modem then the
source IP address isn't 192.168.0.2, it's whatever IP address your ISP
gave you.  Your partner/children/cat surfing the net on a machine whose
local IP address is 192.168.0.3 will also have the IP source address of
their IP packets rewritten to that same IP address that your ISP gave
you -- you will appear to be using the same computer as far as any web
server is concerned.

Some organisations, like the one I work for, use network 10 for internal
IP addresses but any external connections appear to originate from a
public IP address in exactly the same way.   There are a couple of
thousand people on this site all sharing one external IP address, all,
apparently crowded round one screen sharing the same keyboard.

An organisation I used to work for had a class A subnet all of its own,
network 15 and I had a machine whose address was 15.145.139.57 (well, I
might have, I don't remember exactly what it was).  In principle that
machine was able to connect to the external network without any sort of
NAT and, equally, machines from the outside world could connect to it.
In practice, of course, there were (and presumably still are) firewalls
that prevented such traffic.  Access to the Big Bad Internet was (and
maybe still is) through a proxy: this is different to NAT:  routing
happens at the IP packet level; NAT happens at the TCP (or UDP) connect
level; proxying happens at the application protocol level.  You point
Firefox at an HTTP proxy that can either return a page it has prepared
earlier or run the HTTP request on your behalf.  It's a lot more
complicated than that but that's because it's happening at the protocol
level and so involves all kinds of icky details that TCP and IP neither
know nor care about.

And finally, just to round things off, there's a class of proxy called a
transparent proxy.  As far as firefox (or anything else) can tell it's
connecting to the outside world directly, but in practice connections
are redirected to a proxy by some messing by iptables or some similar
cleverness in a Cisco router.   Transparent proxies are quite cool.


Does that help or has it left you even more confused?

jch

Re: Basic Routing

[Grant Taylor]

On 11/04/08 18:00, Daniel L. Miller wrote:
> I guess here's a Linux specific question - as opposed to the more 
> general IP/routing discussion we've been having.

'k

> Given a Linux box with multiple networks on one or more interfaces 
> (192.168.0.1 on eth0, 192.168.5.1 on eth0:0, 172.26.0.1 on eth1, etc.) - 
> and just adding a "1" to /proc/sys/net/ip_forward - will this magic box 
> be able to forward packets between the networks without further 
> configuration?  Or will this require NAT statements from iptables (and 
> no, this is NOT an opportunity to tell me about 
> ipchains/ebtables/other-Linux-networking-specialty-program-kernel-interface-I-didn't-mention)? 

The simple act of enabling IP forwarding (/proc/sys/net/ipv4/ip_forward) 
will allow your Linux box to forward or route traffic between said 
networks (as long as there is no IPTables / etc. to block it).

The problem that you will run in to is whether or not systems on said 
networks will know how to get to systems on the other said networks. 
Will they have a route (default or other wise) that tells them to use 
the Linux router, or will you have to establish routes manually.

Just because you can get a packet somewhere does not mean that you will 
be able to get the reply.

> Ok fine - if you can recommend a tool to make this easier - I'd be 
> delighted to hear about it.  Right now my configuration tool is firehol.

You need to enable IP forwarding (like above) and make sure that each 
system knows that it can reach the other subnets via the Linux router.

So if all the systems are using the Linux router as the /Default 
Gateway/ then things are fine.  If they are not, you need to establish a 
route.  You can either establish routes on all systems, or put one on 
the /Default Gateway/ of each subnet.  Putting the route on the /Default 
Gateway/ in each subnet will cause systems to send traffic to their 
/Default Gateway/ (because the packet is not to their local subnet) 
which will then send it to the router which will then send it to the 
appropriate system.  (This is somewhat sub-optimal, but it will work 
reliably.)

In the end it really comes down to systems /knowing how/ to reach the 
other systems, which is what routing, specifically routes do.



Grant. . . .

Re: Basic Routing

[Grant Taylor]

On 11/04/08 23:21, Rob Sterenborg wrote:
> Grant is doing too good a job... :-)

Thank you.  :)

> Since these IP's are all private you do NOT need NAT.

Agreed.

> Do NOT use NAT in this situation unless you tried plain routing and for 
> some fancy reason, strange situation or requirement you find out you 
> might actually need NAT here. But in your case I don't think you will 
> come to that conclusion unless there's something you haven't told us yet 
> (again: I don't think so).

Agreed.

> Just enable and allow all forwarding, add the routes you need and your 
> magic box will shine like a magic lantern. :^)

Um, mostly agreed.

> iptables -P FORWARD ACCEPT
> iptables -F FORWARD
> echo 1 > /proc/sys/net/ipv4/ip_forward
> route add -net [...etc...]

The part that I want to point out is that the routes that you add will 
not be on the Linux router, but rather the systems on the networks.

Let's look at this example.


          :
        +-+-+         +---+
        | C +---(z)---+ 3 |
        +---+    |    +---+
                 |
   :             |             :
+-+-+         +-+-+         +-+-+
| A +---(x)---+ R +---(y)---+ B |
+---+    |    +---+    |    +---+
          |             |
+---+    |             |    +---+
| 1 +----+             +----+ 2 |
+---+                       +---+

Let's say that this is three independent networks (x, y, and z) with 
their own internet connections (A, B, and C) that you are trying to tie 
together with the Linux router (R).  Each host (1, 2, and 3) will use 
their own internet router (A, B, and C respectively) as their default 
gateway.

One of two things will happen when host 1 wants to talk to host 3.
  1)  Host 1 will not have a route to network z that host 3 is on, so 
host 1 will send the traffic to its default gateway A which would have 
to have a route to send the traffic to router R.
  2)  Host 1 will have a route to network z by way of router R and send 
traffic directly to router R which will then send the traffic to host 3.

> No, this is not secure, but that's not what we're talking about here. 
> This way, your box will effectively be a router. No fancy filtering, 
> NAT-ing, whatever.

Correct.  However that is not to say that filtering and / or NATing 
can't be added if you want to, because they can when you are ready / 
want to do something like that.

> Have a look at http://www.fwbuilder.org/. 
> I'm not using it, I'm not endorsing it, don't know anything of how it 
> builds it's ruleset, etc. It just looks nice if you're coming from MS 
> ISA and you might actually find it handy.

With out having ever used (but have heard of) FWBuilder my self I can't 
comment on it.  However considering how Daniel is asking how things work 
and appears to be trying to learn, I don't think jumping directly in to 
some sort of application that hides this knowledge from him is that good 
of an idea.



Grant. . . .

Re: Basic Routing

[Grant Taylor]

On 11/04/08 17:53, Daniel L. Miller wrote:
> *Head bouncing on desk*  You just had to do it.  You just HAD to throw 
> something else in, didn't you?  Ok - no VPN during these discussions!!! 
> That's next thread.

Ok...  I only brought VPN up because you will want that to tie two 
offices across the internet together.  But if you want to pretend for 
the sake of discussion that you have a really long ethernet cable (or a 
legacy WAN using T1s which use basic routing) I'm ok with that.

> Once again - I'm using language that's too ambiguous.  I actually 
> probably inferred that - but I didn't intend to.  The INTENT was to 
> illustrate a clumsy, inefficient, amateurish connection between Internet 
> connected sites using non-VPN capable home-office consumer-grade 
> firewall routers - the under $20 kind.

Ok.

Be aware that the simple facts that you are using private IP addresses 
and that you want to take them across the internet, where they can not 
go, means that you will have to use NAT.  Remember that the internet 
only caries globally routable IP addresses.

> You're assuming a level of capability and courtesy for the sysadmin I am 
> not - nor am I talking about higher-level protocols.  So from Los 
> Angeles, they'll have to type in the public IP address of the New York 
> router to reach that office.

Eh.  I'm not so much assuming that as I'm trying to lead a horse to 
water that is safe to drink that will also solve the problems that you 
unknowingly are going to have.  If you would prefer to discuss things 
and then get a "That will not work because of..." and then have to 
re-discuss things, we can do that.  :)  Just let me know how you want 
the conversation to go.  In short you are asking questions and providing 
some details of your needs (which keep admittedly by you changing) and I 
am trying to answer them and get you to understand along the way.

> *Exasperated shrug* Now that I've typed that - it really doesn't make 
> too much sense.  All right - fine.  I guess a VPN was needed somewhere.  
> But darn it - the VPN operates at a higher level - somewhere along the 
> line the VPN server/router needs to translate the virtual IP's to 
> something the rest of the world understands - and that means NAT!

No.  VPN's don't /NAT/.  VPN's /encapsulate/.  Think of a VPN as taking 
a letter you wrote to someone and putting it inside of another bigger 
envelope and sending it to someone who opens the outer envelope and 
takes the smaller envelope out and sends it to the proper department on 
their end.

+-----------+    +-------------------+    +----------+
| IP packet | -> | VPN packet        | -> | Internet |
+-----------+    |     +-----------+ |    +----------+
                  |     | IP packet | |
                  |     +-----------+ |
                  +-------------------+

+----------+    +-------------------+    +-----------+
| Internet | -> | VPN packet        | -> | IP packet |
+----------+    |     +-----------+ |    +-----------+
                 |     | IP packet | |
                 |     +-----------+ |
                 +-------------------+

The (IP packet) has host 1 as its source and host 2 as its destination 
and does not change any where in transit.
The [VPN packet ...] has the one VPN gateway as its source and the other 
VPN gateway as its destination.  These packets have the globally 
routable IP addresses in them.

> Again with the proxy (what's the matter with you?  Trying to give me a 
> complete answer that accounts for the exceptions?  Geez....)

Sorry.  :P

Up until recently what you have presented could be solved by basic 
routing and / or NATing -OR- by proxying.  Seeing as how I started off 
indicating that either could be used I was just continuing the concept 
in discussion.  I'll drop it and let you pick it up later if you want to 
inquire about it.  :)

> I think my confusion stems from my own introduction to IP, which was via 
> WindozeNT 4.0.  Somewhere along the line NAT was referred to in some 
> documentation as a "poor-man's solution" to doing "proper" routing - and 
> that concept has carried forward with me to where I keep thinking NAT is 
> somehow an inferior solution to the "proper" way of doing things.  If 
> the only "proper" (read: other) way of connecting LAN's to the Internet 
> is by assigning public IP's to workstations (and of course 
> purchasing/reserving/controlling such IP's) - then I can drop the 
> inferiority complex I've held with regard to NAT.

Ugh.  Forgive me if I believe just from the statement about where you 
learned about routing (not even taking in to consideration this 
discussion) that you were not taught hardly any thing (if even that) 
about routing.  It has been my experience that /most/ information that 
Microsoft has provided on routing was the smallest amount that they 
could to even thing about stepping up and playing with the big boys.  It 
is my opinion that Microsoft network was and still is to a large part 
NetBIOS based, even if it is on top of TCP/IP.  Even that, the TCP/IP is 
simply a happenstance as a carrier protocol that could just as easily 
been IPX or DECNet Phase IV.

There was a time that (in my opinion) /most/ Windows technicians would 
have thought that the only two ways to get a Windows machine to access 
the internet was with live globally routable IPs assigned to all the 
workstations using ""proper routing -OR- to use NAT.  However there was 
/ is this other seldom used technology that I'm no longer mentioning.  ;)

At this point I don't really see any questions, just comments on things, 
so I'm going to let you lead the conversation by asking some other 
questions, which I'll respond to.  :)



Grant. . . .

Re: Basic Routing

[Grant Taylor]

On 11/05/08 06:24, John Haxby wrote:
> Perhaps the problem is that the good people on this list know just 
> too much about the finer points of routing and the caveats and 
> wrinkles that you occasionally need to avoid special purpose 
> problems.

*nod* (guilty) *nod*

> For the most part, though, it's actually quite simple.   And I know 
> that some of the things I will say are wrong in some cases and I 
> would hope that someone will explain to me where they're wrong and 
> maybe we'll all be enlightened.

I don't see any thing wrong with what you have said.  I might have used 
different wording, but we are two different humans.  :)

<snip>

I do have a quick comment to add about the routing table though.  The 
routing table is ordered with the most specific match first (what you 
were getting at by the number of zeros).  So when the routing table is 
searched, the first route to be found, the most specific one, is the 
proper one.  The reason you might have a more specific route and a less 
specific route is if you have a fast high latency satellite connection 
to and a slow low latency dial up or leased line connection back to 
corporate.  You would want the bulk of (non interactive) traffic to go 
through the faster high latency connection for most things but still 
have smaller interactive (think terminal type) traffic go over the 
slower lower latency dial up / leased line.  To be able to do this you 
would put the destination server equipment for the interactive traffic 
be in a smaller ""special part of the larger address range.  Then you 
tell the router that it has access to the smaller range over the dial up 
and the rest of the address range across the satellite.

The more specific routes can be used to override less specific routes.

> Does that help or has it left you even more confused?

I'm guessing that it left Daniel with more to think about and to 
formulate more questions.  Which is in and of it self a good thing as 
that is the normal process of learning.  :)



Grant. . . .

RE: Basic Routing

[Rob Sterenborg]

>> Grant is doing too good a job... :-)
> 
> Thank you.  :)

You're welcome.. Heheh.

>> Just enable and allow all forwarding, add the routes you need and
>> your magic box will shine like a magic lantern. :^)
> 
> Um, mostly agreed.

You mean you don't agree to the shining part?

>> iptables -P FORWARD ACCEPT
>> iptables -F FORWARD
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> route add -net [...etc...]
> 
> The part that I want to point out is that the routes that you
> add will not be on the Linux router, but rather the systems on
> the networks.

Yes, well, in the basic example I was refering to (A <-> C <-> D <-> B),
routers C and D already know the routes to the networks they're connected to
(and I assume that hosts in A and B have a (default) route to C and D resp)
so they don't need extra routes. But they do need forwarding set to ACCEPT
and allowed. In a more complex situation things are different.

>> Have a look at http://www.fwbuilder.org/.
>> I'm not using it, I'm not endorsing it, don't know anything of how it
>> builds it's ruleset, etc. It just looks nice if you're coming from MS
>> ISA and you might actually find it handy.
> 
> With out having ever used (but have heard of) FWBuilder my self I
> can't comment on it.  However considering how Daniel is asking how
> things work and appears to be trying to learn, I don't think jumping
> directly in to some sort of application that hides this knowledge from
> him is that good of an idea.

No, I don't think so too. I already pointed him to Oskars iptables tutorial
which I think still mostly holds and I hope he'll read (and understand) it.
Writing your own script is still more flexible and you learn more about what
you're doing and dealing with.


Grts,
Rob

Re: Basic Routing

[Grant Taylor]

On 11/05/08 12:22, Rob Sterenborg wrote:
> You mean you don't agree to the shining part?

Oh, no, the shine part is fine.  I was more thinking about where the 
routes were.

> Yes, well, in the basic example I was refering to (A <-> C <-> D <-> 
> B), routers C and D already know the routes to the networks they're 
> connected to (and I assume that hosts in A and B have a (default) 
> route to C and D resp) so they don't need extra routes. But they do 
> need forwarding set to ACCEPT and allowed. In a more complex 
> situation things are different.

Um, very close but not /quite/.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

A knows about network x.
C knows about networks x and y.
D knows about networks y and z.
B knows about network z.

C does /not/ know about network z.
D does /not/ know about network x.

So either C and D have to use each other ad default gateways or they 
have to have routes to networks x and z.  (That's the "not quite" part.)

We have already covered the IP forwarding in another email.  As far as 
the firewalling is concerned, you are correct.  However I believe Daniel 
said that there was no firewalling (yet).

> No, I don't think so too. I already pointed him to Oskars iptables 
> tutorial which I think still mostly holds and I hope he'll read (and 
> understand) it. Writing your own script is still more flexible and 
> you learn more about what you're doing and dealing with.

Agreed.  I think both are likely good ways to learn about firewalling, 
specifically IPTables.  Seeing as how this discussion is about routing...



Grant. . . .

RE: Basic Routing

[Rob Sterenborg]

> +---+         +---+         +---+         +---+
> | A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
> +---+         +---+         +---+         +---+
> 
> A knows about network x.
> C knows about networks x and y.
> D knows about networks y and z.
> B knows about network z.
> 
> C does /not/ know about network z.
> D does /not/ know about network x.

Yes you're correct.. I should stop assuming things that I already
figured out in my head but don't write down when replying. (Actually, a
"few" emails ago I wrote an email that describes the exact same as the
above -including art- but I discarded it when I saw your answer which
was even more complete.)

> We have already covered the IP forwarding in another email.  As far
> as the firewalling is concerned, you are correct.  However I believe
> Daniel said that there was no firewalling (yet).

Nope, there was no word about firewalling, just NAT and routing.

> Agreed.  I think both are likely good ways to learn about
> firewalling, specifically IPTables.  Seeing as how this
> discussion is about routing...

We started with NAT, which is something that netfilter can do and what
the tutorial also describes, and routing. I was hoping that Daniel would
see why he didn't need NAT by reading it.

Daniel, this is getting lengthy and I think everything that needed to be
said has been said about NAT and routing. I hope things are (more) clear
now.


Grts,
Rob

Re: Basic Routing

[Daniel L. Miller]

  On 11/5/2008 9:31 AM, Grant Taylor wrote:
> On 11/05/08 06:24, John Haxby wrote:
>> Perhaps the problem is that the good people on this list know just 
>> too much about the finer points of routing and the caveats and 
>> wrinkles that you occasionally need to avoid special purpose problems.
>
> *nod* (guilty) *nod*
>
>> Does that help or has it left you even more confused?
>
> I'm guessing that it left Daniel with more to think about and to 
> formulate more questions.  Which is in and of it self a good thing as 
> that is the normal process of learning.  :)
>
>
Once upon a time I asked this list some routing questions.  I've almost 
got it - I swear I've ALMOST got it.  One more little push and I think 
I'm there.

Given the specific architecture:
Windows Workstation 192.168.5.100, default gateway 192.168.5.1
Linux Gateway/Router/VPN node 192.168.7.2, 192.168.5.1, 192.168.0.90, 
default gateway 192.168.7.1
DSL Modem 192.168.7.1

Linux Server/Router/VPN server/Virtual Server 192.168.0.71, 
192.168.56.1, default gateway 192.168.0.1
Virtual Machine 192.168.56.20, default gateway 192.168.56.1

What is the "easiest" way of "achieving routing" between the Windows 
Workstation and the Virtual Machine?  Is this an instance where NAT 
would make administration simpler instead of "pure" routing?  The 
cumbersome-but-working method I have employed at the moment includes;

add 192.168.56.0/24 via 192.168.0.71 route to Workstation
add 192.168.56.0/24 via 192.168.0.71 route to Linux Gateway
add 192.168.5.0/24 via 192.168.0.90 route to Linux Server

I almost understand the need for the 192.168.5.0/24 entry on the Linux 
Server side - because otherwise the router doesn't know how to reply, 
and the same goes for the 192.168.56.0/24 entry on the Gateway side - 
otherwise the Gateway doesn't know how to reach that subnet in the first 
place.  But, if the Gateway is defined as the default for the 
Workstation, why is a routing entry required for the Workstation?
-- 
Daniel

Re: Basic Routing

[Jan Engelhardt]

On Monday 2010-09-20 23:40, Daniel L. Miller wrote:
>
> Given the specific architecture:
> Windows Workstation 192.168.5.100, default gateway 192.168.5.1
> Linux Gateway/Router/VPN node 192.168.7.2, 192.168.5.1, 192.168.0.90, default
> gateway 192.168.7.1
> DSL Modem 192.168.7.1
>
> Linux Server/Router/VPN server/Virtual Server 192.168.0.71, 192.168.56.1,
> default gateway 192.168.0.1
> Virtual Machine 192.168.56.20, default gateway 192.168.56.1

graph {
	windows -- lxgateway;
	lxgateway -- dsl;
	lxgateway -- vserver;
	vserser -- vm;
};

>
> What is the "easiest" way of "achieving routing" between the Windows
> Workstation and the Virtual Machine?  Is this an instance where NAT would make
> administration simpler instead of "pure" routing?  The cumbersome-but-working
> method I have employed at the moment includes;

NAT wouldn't fix anything.

> add 192.168.56.0/24 via 192.168.0.71 route to Workstation
> add 192.168.56.0/24 via 192.168.0.71 route to Linux Gateway
> add 192.168.5.0/24 via 192.168.0.90 route to Linux Server

That won't work because
- 192.168.0.71/32 is a nonexisting route on Workstation (at least I
  suppose that this is the case currently)
- 56.0/24 via 0.71 is redundant because you've got a default route
  through lxgateway anyway
- You don't really need the .0.0/24.

Do:

lxgateway:
- addr: 192.168.5.1/24 dev ethwork
- addr: 192.168.5.1/32 dev ethvserver
- route: 192.168.5.0/24 dev ethwork (automatic)
- route: 192.168.56.1/32 dev ethvserver
- route: 192.168.56.0/24 via 192.168.56.1
Workstation:
- addr: 192.168.5.X/24 dev eth0
- route: default via 192.168.5.1
vserver:
- addr: 192.168.56.1/24 dev ethvms
- addr: 192.168.56.1/32 dev ethmain
- route: 192.168.56.0/24 dev ethvms (automatic)
- route: 192.168.5.1/32 dev ethmain
- route: default via 192.168.5.1
vms:
- addr: 192.168.56.X/24 dev eth0
- route: default via 192.168.56.1

> I almost understand the need for the 192.168.5.0/24 entry on the
> Linux Server side - because otherwise the router doesn't know how
> to reply, and the same goes for the 192.168.56.0/24 entry on the
> Gateway side - otherwise the Gateway doesn't know how to reach that
> subnet in the first place. But, if the Gateway is defined as the
> default for the Workstation, why is a routing entry required for
> the Workstation?

It is in fact not required.

Re: Basic Routing

[Grant Taylor]

Daniel L. Miller wrote:
> Once upon a time I asked this list some routing questions.  I've almost 
> got it - I swear I've ALMOST got it.  One more little push and I think 
> I'm there.

*chuckle*

Here's a *nudge* to help you get there.  ;-)

> Given the specific architecture:
> Windows Workstation 192.168.5.100, default gateway 192.168.5.1
> Linux Gateway/Router/VPN node 192.168.7.2, 192.168.5.1, 192.168.0.90, 
> default gateway 192.168.7.1
> DSL Modem 192.168.7.1

It sounds like your Windows workstation (192.168.5.100) uses your Linux 
router (192.168.5.1) as its default gateway and that your Linux router 
(192.168.5.1, 192.168.7.2 and 192.168.0.90) uses your DSL modem 
(192.168.7.1) as its default router.

(Windows)---(Linux)---(DSL)---(Internet)

Correct?

> Linux Server/Router/VPN server/Virtual Server 192.168.0.71, 
> 192.168.56.1, default gateway 192.168.0.1
> Virtual Machine 192.168.56.20, default gateway 192.168.56.1

It sounds like your virtual machine (192.168.56.20) uses your Linux 
router (192.168.56.1) as its default gateway and that your Linux router 
(192.168.56.1, 192.168.0.7) uses <something> (192.168.0.1) as its 
default gateway.

(VM)---(Linux)---(<something>)---(Internet)

Correct?

I'm not sure what the <something> is that has the IP address 192.168.0.1.

Further, I can't tell if the 192.168.0.x networks on the two Linux 
routers is the same network (or VPN) or not.  -  For the sake of 
conversation (and demonstration) I'm going to continue as if they are.

If the above two system share the 192.168.0.x network, we end up with a 
topology that might be depicted like this:


                +---(DSL)---(Internet)
                |
(Windows)---(Linux)---+
                       |
                       +---(<something>)---(Internet)
                       |
      (VM)---(Linux)---+

Or via IP:



                                       +---(192.168.7.1)---(0.0.0.0/0)
                                       |
(192.168.5.100)---(192.168.5.1, 192.168.7.2, 192.168.0.90)---+
                                                              |
 
+---(192.168.0.1)---(0.0.0.0/0)
                                                              |
             (192.168.56.20)---(192.168.56.1, 192.168.0.71)---+

(I'm not sure if that's going to work wrap properly or not.)

I'm going to take a stab and presume that the what you are calling 
"Linux Gateway/Router/VPN node" is a VPN client that is connected to 
what you are calling "Linux Server/Router/VPN server/Virtual Server" and 
that it is being bridged in to the 192.168.0/24 network.

Correct?

For the sake of conversation (and demonstration) I'm going to continue 
as if I am correct.

> What is the "easiest" way of "achieving routing" between the Windows 
> Workstation and the Virtual Machine?

Add a route to the "Linux Gateway/Router/VPN node" so that it knows that 
it can get to the 192.168.56/24 network via the "Linux Server/Router/VPN 
server/Virtual Server" (192.168.0.71).  And vice versa, add a route to 
the "Linux Server/Router/VPN server/Virtual Server" so that it knows 
that it can get to the 192.168.5/24 network via the "Linux 
Gateway/Router/VPN node" (192.168.0.90).

> Is this an instance where NAT 
> would make administration simpler instead of "pure" routing?  The 
> cumbersome-but-working method I have employed at the moment includes;

No.  NAT is seldom a better solution than "pure" routing.

> add 192.168.56.0/24 via 192.168.0.71 route to Workstation

The workstation doesn't need to explicitly have a route because it's 
default gateway has one.

> add 192.168.56.0/24 via 192.168.0.71 route to Linux Gateway
> add 192.168.5.0/24 via 192.168.0.90 route to Linux Server

That's all you should need to do.

I am curious, why do you consider this to be "cumbersome"?

> I almost understand the need for the 192.168.5.0/24 entry on the Linux 
> Server side - because otherwise the router doesn't know how to reply, 
> and the same goes for the 192.168.56.0/24 entry on the Gateway side - 
> otherwise the Gateway doesn't know how to reach that subnet in the first 
> place.  But, if the Gateway is defined as the default for the 
> Workstation, why is a routing entry required for the Workstation?

No, the routing is not required on the Windows workstation or the 
virtual machine because their respective default gateways know the 
routes for them.

You did find your answer, but hopefully this will help you understand 
why the answer you found works.

It might not be obvious, and seem to complicate things, but I don't 
think I would bridge the VPN client in to the VPN server's network.  I 
would rather set up a small network between the VPN client and the VPN 
server and set up routes on the VPN server to what is on either end. 
(In your case, it would be a matter of changing the next hop gateway / 
router that the "Linux Server/Router/VPN server/Virtual Server" used.) 
Doing this will help prevent spurious traffic from the 192.168.0/24 
network from going through the VPN to the "Linux Gateway/Router/VPN 
node".  Further, you will have the capability for more security on the 
"Linux Server/Router/VPN server/Virtual Server" in such as you can use 
IPTables to firewall (based on network) the VPN traffic.  Also, your 
(completely) "Linux Gateway/Router/VPN node" is dependent on the 
configuration of the 192.168.0/24 network, where as if it was routed, 
you would simply need a route referencing the "Linux Server/Router/VPN 
server/Virtual Server", with out caring what is on the other side of the 
"Linux Server/Router/VPN server/Virtual Server", there by separating the 
networks.  As it is (using bridging) you can't change things (addresses 
/ network config / etc.) on the 192.168.0/24 network with out 
re-configuring the "Linux Gateway/Router/VPN node".

Setting up the additional routed VPN may seem like extra work, but it 
allows for abstraction / isolation / simplification of things for 
changes later.  -  Comparing things to the internet, think what would 
happen if you had to re-configure your internet connection every time 
your ISP made changes (additions / removal) to their back haul 
providers.  Routing allows you to simply rely on your ISP's upstream 
(gateway) IP, and let them worry about what is beyond that.  ;-)



Grant. . . .

Basic routing

[John Smithee]

Hi,

I've 2 NICs on a machine, both attached to seperate networks
(192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
basic gateway (or routing?) between the two networks.

The first network has a gateway to other networks behind it,
it can reach all networks well, incl. the first network.

The second network can reach the first, but reaching anything
beyond (ie. the other networks behind the first network) is
somehow not possible.

Only IPv4 is used, and IP forwarding on the machine is enabled (ie. 
net.ipv4.ip_forward=1 in /etc/sysctl.conf).

Is this a classical routing issue or has this to be done via iptables?

I rather would like to keep the original IPs in the packet headers,
ie. not use NAT, and also not use bridging.
How can this be done?

Re: Basic routing

[John Smithee]

John Smithee wrote, On 10/04/2014 03:10 AM:
> Hi,
>
> I've 2 NICs on a machine, both attached to seperate networks
> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
> basic gateway (or routing?) between the two networks.
>
> The first network has a gateway to other networks behind it,
> it can reach all networks well, incl. the first network.
>
> The second network can reach the first, but reaching anything
> beyond (ie. the other networks behind the first network) is
> somehow not possible.
>
> Only IPv4 is used, and IP forwarding on the machine is enabled (ie.
> net.ipv4.ip_forward=1 in /etc/sysctl.conf).
>
> Is this a classical routing issue or has this to be done via iptables?
>
> I rather would like to keep the original IPs in the packet headers,
> ie. not use NAT, and also not use bridging.
> How can this be done?


Here's some more info:


# /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet static
   address   192.168.68.22
   netmask   255.255.255.0
   broadcast 192.168.68.255
   gateway   192.168.68.254

auto eth1
allow-hotplug eth1
iface eth1 inet static
   address   192.168.69.22
   netmask   255.255.255.0
   broadcast 192.168.69.255



# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.68.254  0.0.0.0         UG    0      0        0 eth0
link-local      *               255.255.0.0     U     1      0        0 eth0
192.168.68.0    *               255.255.255.0   U     1      0        0 eth0
192.168.69.0    *               255.255.255.0   U     0      0        0 eth1



Pinging the external gateway (192.168.68.254) from eth0 works fine,
but not from eth1:

# ping -I eth1 192.168.68.254
PING 192.168.68.254 (192.168.68.254) from 192.168.69.22 eth1: 56(84) bytes of 
data.
 From 192.168.69.22 icmp_seq=1 Destination Host Unreachable
 From 192.168.69.22 icmp_seq=2 Destination Host Unreachable
 From 192.168.69.22 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.68.254 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4022ms

Re: Basic routing

[Neal Murphy]

On Friday, October 03, 2014 09:10:58 PM John Smithee wrote:
> Hi,
> 
> I've 2 NICs on a machine, both attached to seperate networks
> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
> basic gateway (or routing?) between the two networks.
> 
> Is this a classical routing issue or has this to be done via iptables?

Standard networking, standard routing. Netfilter doesn't enter the equation.

The prime directive: every router must have explicit routes to all networks it 
can reach, except that the default route can eliminate many explicit routes. 
In other words, "These routes specify how to reach these LANs; packets for all 
other networks will be sent via the default route if it exists. Packets for 
which there is no route will be dribbled into the bit bucket." Note the phrase 
"every router"; it include all of your internal routers as well as your 
perimeter (default) gateway.

For a router to transmit a packet it must know *where* to send it. Your 
machine must have explicit routes to networks reachable via 192.168.68.X and 
explicit routes to networks reachable via 192.168.69.Y, where the X and Y 
addresses are the addresses of the routers that are gateways to those other 
LANs.
----
  ip route add 10.20.30.0/24 via 192.168.69.34
  ip route add 192.168.128.0/17 via 192.168.68.200
  etc.
----

If your 'internetwork' includes the universe (the Internet), you need a 
default route (send all packets I don't have a route for to this address).
----
  ip route add default via 192.168.68.254
----

Re: Basic routing

[John Smithee]

Neal Murphy wrote, On 10/04/2014 03:34 AM:
> On Friday, October 03, 2014 09:10:58 PM John Smithee wrote:
>> Hi,
>>
>> I've 2 NICs on a machine, both attached to seperate networks
>> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
>> basic gateway (or routing?) between the two networks.
>>
>> Is this a classical routing issue or has this to be done via iptables?
>
> Standard networking, standard routing. Netfilter doesn't enter the equation.
>
> The prime directive: every router must have explicit routes to all networks it
> can reach, except that the default route can eliminate many explicit routes.
> In other words, "These routes specify how to reach these LANs; packets for all
> other networks will be sent via the default route if it exists. Packets for
> which there is no route will be dribbled into the bit bucket." Note the phrase
> "every router"; it include all of your internal routers as well as your
> perimeter (default) gateway.
>
> For a router to transmit a packet it must know *where* to send it. Your
> machine must have explicit routes to networks reachable via 192.168.68.X and
> explicit routes to networks reachable via 192.168.69.Y, where the X and Y
> addresses are the addresses of the routers that are gateways to those other
> LANs.
> ----
>    ip route add 10.20.30.0/24 via 192.168.69.34
>    ip route add 192.168.128.0/17 via 192.168.68.200
>    etc.
> ----
>
> If your 'internetwork' includes the universe (the Internet), you need a
> default route (send all packets I don't have a route for to this address).
> ----
>    ip route add default via 192.168.68.254
> ----

Thx, yes this is indeed standard IP networking stuff, but unfortunately
it still isn't working; there must be something more to it.

I think the ping error text is perhaps misleading: I guess the ping request
does reach the destination, but the answer packet from the ping reply
gets not forwarded to the originating second interface eth1 (192.168.69.*).

Ie. the the request from eth1 correctly goes out thru the eth0 interface
and the reply comes as well over the same eth0 interface,
but there is on the return path something missing to forward it from
eth0 to eth1. Isn't it?

Re: Basic routing

[Dennis Jacobfeuerborn]

On 04.10.2014 04:52, John Smithee wrote:
> Neal Murphy wrote, On 10/04/2014 03:34 AM:
>> On Friday, October 03, 2014 09:10:58 PM John Smithee wrote:
>>> Hi,
>>>
>>> I've 2 NICs on a machine, both attached to seperate networks
>>> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
>>> basic gateway (or routing?) between the two networks.
>>>
>>> Is this a classical routing issue or has this to be done via iptables?
>>
>> Standard networking, standard routing. Netfilter doesn't enter the
>> equation.
>>
>> The prime directive: every router must have explicit routes to all
>> networks it
>> can reach, except that the default route can eliminate many explicit
>> routes.
>> In other words, "These routes specify how to reach these LANs; packets
>> for all
>> other networks will be sent via the default route if it exists.
>> Packets for
>> which there is no route will be dribbled into the bit bucket." Note
>> the phrase
>> "every router"; it include all of your internal routers as well as your
>> perimeter (default) gateway.
>>
>> For a router to transmit a packet it must know *where* to send it. Your
>> machine must have explicit routes to networks reachable via
>> 192.168.68.X and
>> explicit routes to networks reachable via 192.168.69.Y, where the X and Y
>> addresses are the addresses of the routers that are gateways to those
>> other
>> LANs.
>> ----
>>    ip route add 10.20.30.0/24 via 192.168.69.34
>>    ip route add 192.168.128.0/17 via 192.168.68.200
>>    etc.
>> ----
>>
>> If your 'internetwork' includes the universe (the Internet), you need a
>> default route (send all packets I don't have a route for to this
>> address).
>> ----
>>    ip route add default via 192.168.68.254
>> ----
> 
> Thx, yes this is indeed standard IP networking stuff, but unfortunately
> it still isn't working; there must be something more to it.
> 
> I think the ping error text is perhaps misleading: I guess the ping request
> does reach the destination, but the answer packet from the ping reply
> gets not forwarded to the originating second interface eth1 (192.168.69.*).
> 
> Ie. the the request from eth1 correctly goes out thru the eth0 interface
> and the reply comes as well over the same eth0 interface,
> but there is on the return path something missing to forward it from
> eth0 to eth1. Isn't it?

Have you tried doing a tcpdump on eth0 while the ping is running to see
if packets are actually leaving the system and/or returning?

Regards,
  Dennis

Re: Basic routing

[Neal Murphy]

On Friday, October 03, 2014 10:52:06 PM John Smithee wrote:
> Neal Murphy wrote, On 10/04/2014 03:34 AM:
> > On Friday, October 03, 2014 09:10:58 PM John Smithee wrote:
> >> Hi,
> >> 
> >> I've 2 NICs on a machine, both attached to seperate networks
> >> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
> >> basic gateway (or routing?) between the two networks.
> >> 
> >> Is this a classical routing issue or has this to be done via iptables?
> > 
> > Standard networking, standard routing. Netfilter doesn't enter the
> > equation.
> > 
> > The prime directive: every router must have explicit routes to all
> > networks it can reach, except that the default route can eliminate many
> > explicit routes. In other words, "These routes specify how to reach
> > these LANs; packets for all other networks will be sent via the default
> > route if it exists. Packets for which there is no route will be dribbled
> > into the bit bucket." Note the phrase "every router"; it include all of
> > your internal routers as well as your perimeter (default) gateway.
> > 
> > For a router to transmit a packet it must know *where* to send it. Your
> > machine must have explicit routes to networks reachable via 192.168.68.X
> > and explicit routes to networks reachable via 192.168.69.Y, where the X
> > and Y addresses are the addresses of the routers that are gateways to
> > those other LANs.
> > ----
> > 
> >    ip route add 10.20.30.0/24 via 192.168.69.34
> >    ip route add 192.168.128.0/17 via 192.168.68.200
> >    etc.
> > 
> > ----
> > 
> > If your 'internetwork' includes the universe (the Internet), you need a
> > default route (send all packets I don't have a route for to this
> > address). ----
> > 
> >    ip route add default via 192.168.68.254
> > 
> > ----
> 
> Thx, yes this is indeed standard IP networking stuff, but unfortunately
> it still isn't working; there must be something more to it.
> 
> I think the ping error text is perhaps misleading: I guess the ping request
> does reach the destination, but the answer packet from the ping reply
> gets not forwarded to the originating second interface eth1 (192.168.69.*).
> 
> Ie. the the request from eth1 correctly goes out thru the eth0 interface
> and the reply comes as well over the same eth0 interface,
> but there is on the return path something missing to forward it from
> eth0 to eth1. Isn't it?

Actually, your ping (below) works correctly. '-I eth1' tells ping to send the 
packet out that interface; linux doesn't know where to send the packet on that 
IF and correctly says the host is unreachable. (Technically, it send ARP 
requests out but gets no response, as expected.)

Use 'ping -I 192.168.69.22' to use that address on pings going out the other 
IF.

> auto eth0
> allow-hotplug eth0
> iface eth0 inet static
>    address   192.168.68.22
>    netmask   255.255.255.0
>    broadcast 192.168.68.255
>    gateway   192.168.68.254
> 
> auto eth1
> allow-hotplug eth1
> iface eth1 inet static
>    address   192.168.69.22
>    netmask   255.255.255.0
>    broadcast 192.168.69.255
> 
> 
> 
> # route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
> default         192.168.68.254  0.0.0.0         UG    0      0        0 eth0
> link-local      *               255.255.0.0     U     1      0        0 eth0
> 192.168.68.0    *               255.255.255.0   U     1      0        0 eth0
> 192.168.69.0    *               255.255.255.0   U     0      0        0 eth1
> 
> 
> 
> Pinging the external gateway (192.168.68.254) from eth0 works fine,
> but not from eth1:
> 
> # ping -I eth1 192.168.68.254
> PING 192.168.68.254 (192.168.68.254) from 192.168.69.22 eth1: 56(84) bytes 
of 
> data.
>  From 192.168.69.22 icmp_seq=1 Destination Host Unreachable
>  From 192.168.69.22 icmp_seq=2 Destination Host Unreachable
>  From 192.168.69.22 icmp_seq=3 Destination Host Unreachable
> ^C
> --- 192.168.68.254 ping statistics ---
> 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4022ms
> 

Re: Basic routing

[John Lister]

On 04/10/2014 03:52, John Smithee wrote:
> Neal Murphy wrote, On 10/04/2014 03:34 AM:
>> On Friday, October 03, 2014 09:10:58 PM John Smithee wrote:
>>> Hi,
>>>
>>> I've 2 NICs on a machine, both attached to seperate networks
>>> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
>>> basic gateway (or routing?) between the two networks.
>>>
>>> Is this a classical routing issue or has this to be done via iptables?
>>
>> Standard networking, standard routing. Netfilter doesn't enter the 
>> equation.
>>
>> The prime directive: every router must have explicit routes to all 
>> networks it
>> can reach, except that the default route can eliminate many explicit 
>> routes.
>> In other words, "These routes specify how to reach these LANs; 
>> packets for all
>> other networks will be sent via the default route if it exists. 
>> Packets for
>> which there is no route will be dribbled into the bit bucket." Note 
>> the phrase
>> "every router"; it include all of your internal routers as well as your
>> perimeter (default) gateway.
>>
>> For a router to transmit a packet it must know *where* to send it. Your
>> machine must have explicit routes to networks reachable via 
>> 192.168.68.X and
>> explicit routes to networks reachable via 192.168.69.Y, where the X 
>> and Y
>> addresses are the addresses of the routers that are gateways to those 
>> other
>> LANs.
>> ----
>>    ip route add 10.20.30.0/24 via 192.168.69.34
>>    ip route add 192.168.128.0/17 via 192.168.68.200
>>    etc.
>> ----
>>
>> If your 'internetwork' includes the universe (the Internet), you need a
>> default route (send all packets I don't have a route for to this 
>> address).
>> ----
>>    ip route add default via 192.168.68.254
>> ----
>
> Thx, yes this is indeed standard IP networking stuff, but unfortunately
> it still isn't working; there must be something more to it.
>
> I think the ping error text is perhaps misleading: I guess the ping 
> request
> does reach the destination, but the answer packet from the ping reply
> gets not forwarded to the originating second interface eth1 
> (192.168.69.*).
>
> Ie. the the request from eth1 correctly goes out thru the eth0 interface
> and the reply comes as well over the same eth0 interface,
> but there is on the return path something missing to forward it from
> eth0 to eth1. Isn't it?
>
You are trying to ping an address on eth0 using eth1, in otherwords you 
are saying the traffic MUST leave on eth1 and somehow find its way to 
eth0. The destination host unreachable is the return packet saying that 
this is impossible. You probably have no route setup to direct traffic 
from 69.x to 68.x and I suspect even with one it would fail as by using 
-I with ping you are forcing the output network device. Generally you 
would use -I if there were 2 routes to an external device to test both 
are working, in this instance the routing is internal but you are 
telling ping it needs to transmit the packet.

If you really want to do this, you could add some ip tables rules to 
intercept traffic on eth1 going to 68.x and switch the source 
interface/address

John

>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Basic routing

[George Botye]

On 04/10/14 02:24, John Smithee wrote:
> John Smithee wrote, On 10/04/2014 03:10 AM:
>> Hi,
>>
>> I've 2 NICs on a machine, both attached to seperate networks
>> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
>> basic gateway (or routing?) between the two networks.
>>
>> The first network has a gateway to other networks behind it,
>> it can reach all networks well, incl. the first network.
>>
>> The second network can reach the first, but reaching anything
>> beyond (ie. the other networks behind the first network) is
>> somehow not possible.
>>
>> Only IPv4 is used, and IP forwarding on the machine is enabled (ie.
>> net.ipv4.ip_forward=1 in /etc/sysctl.conf).
>>
>> Is this a classical routing issue or has this to be done via iptables?
>>
>> I rather would like to keep the original IPs in the packet headers,
>> ie. not use NAT, and also not use bridging.
>> How can this be done?
>
>
> Here's some more info:
>
>
> # /etc/network/interfaces
> auto lo
> iface lo inet loopback
>
> auto eth0
> allow-hotplug eth0
> iface eth0 inet static
>   address   192.168.68.22
>   netmask   255.255.255.0
>   broadcast 192.168.68.255
>   gateway   192.168.68.254
>
> auto eth1
> allow-hotplug eth1
> iface eth1 inet static
>   address   192.168.69.22
>   netmask   255.255.255.0
>   broadcast 192.168.69.255
>
>
>
> # route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    
> Use Iface
> default         192.168.68.254  0.0.0.0         UG    0 0        0 eth0
> link-local      *               255.255.0.0     U     1 0        0 eth0
> 192.168.68.0    *               255.255.255.0   U     1 0        0 eth0
> 192.168.69.0    *               255.255.255.0   U     0 0        0 eth1
>
>
>
> Pinging the external gateway (192.168.68.254) from eth0 works fine,
> but not from eth1:
>
> # ping -I eth1 192.168.68.254
> PING 192.168.68.254 (192.168.68.254) from 192.168.69.22 eth1: 56(84) 
> bytes of data.
> From 192.168.69.22 icmp_seq=1 Destination Host Unreachable
> From 192.168.69.22 icmp_seq=2 Destination Host Unreachable
> From 192.168.69.22 icmp_seq=3 Destination Host Unreachable
> ^C
> --- 192.168.68.254 ping statistics ---
> 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 
> 4022ms
>
>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
>
Hi,

Drawing always helps you... :-)

         eth0                                                   eth1
|                                                          |
           V                                                        V
--------------------- ---------------------
| 192.168.68.0 |        <---???--->       | 192.168.69.0 |
--------------------- ---------------------

Please imagine what happen with packet addressed to 192.168.68.254 in 
192.168.69.0/24.
(I suggest read this http://www.tldp.org/LDP/nag2/nag2.pdf)

Regards, George

Re: Basic routing

[John Smithee]

John Lister wrote, On 10/04/2014 09:04 AM:
>
> On 04/10/2014 03:52, John Smithee wrote:
>> Neal Murphy wrote, On 10/04/2014 03:34 AM:
>>> On Friday, October 03, 2014 09:10:58 PM John Smithee wrote:
>>>> Hi,
>>>>
>>>> I've 2 NICs on a machine, both attached to seperate networks
>>>> (192.168.68.0/24 and 192.168.69.0/24). I'm trying to set up a
>>>> basic gateway (or routing?) between the two networks.
>>>>
>>>> Is this a classical routing issue or has this to be done via iptables?
>>>
>>> Standard networking, standard routing. Netfilter doesn't enter the equation.
>>>
>>> The prime directive: every router must have explicit routes to all networks it
>>> can reach, except that the default route can eliminate many explicit routes.
>>> In other words, "These routes specify how to reach these LANs; packets for all
>>> other networks will be sent via the default route if it exists. Packets for
>>> which there is no route will be dribbled into the bit bucket." Note the phrase
>>> "every router"; it include all of your internal routers as well as your
>>> perimeter (default) gateway.
>>>
>>> For a router to transmit a packet it must know *where* to send it. Your
>>> machine must have explicit routes to networks reachable via 192.168.68.X and
>>> explicit routes to networks reachable via 192.168.69.Y, where the X and Y
>>> addresses are the addresses of the routers that are gateways to those other
>>> LANs.
>>> ----
>>>    ip route add 10.20.30.0/24 via 192.168.69.34
>>>    ip route add 192.168.128.0/17 via 192.168.68.200
>>>    etc.
>>> ----
>>>
>>> If your 'internetwork' includes the universe (the Internet), you need a
>>> default route (send all packets I don't have a route for to this address).
>>> ----
>>>    ip route add default via 192.168.68.254
>>> ----
>>
>> Thx, yes this is indeed standard IP networking stuff, but unfortunately
>> it still isn't working; there must be something more to it.
>>
>> I think the ping error text is perhaps misleading: I guess the ping request
>> does reach the destination, but the answer packet from the ping reply
>> gets not forwarded to the originating second interface eth1 (192.168.69.*).
>>
>> Ie. the the request from eth1 correctly goes out thru the eth0 interface
>> and the reply comes as well over the same eth0 interface,
>> but there is on the return path something missing to forward it from
>> eth0 to eth1. Isn't it?
>>
> You are trying to ping an address on eth0 using eth1, in otherwords you are
> saying the traffic MUST leave on eth1 and somehow find its way to eth0. The
> destination host unreachable is the return packet saying that this is
> impossible. You probably have no route setup to direct traffic from 69.x to
> 68.x and I suspect even with one it would fail as by using -I with ping you
> are forcing the output network device. Generally you would use -I if there
> were 2 routes to an external device to test both are working, in this instance
> the routing is internal but you are telling ping it needs to transmit the packet.
>
> If you really want to do this, you could add some ip tables rules to intercept
> traffic on eth1 going to 68.x and switch the source interface/address
>
> John

Ok, I admit using "ping -I" was a bad example. The whole point I tried
to make is, that the second net (69.0) cannot reach any other IP outside its 
own net.
The goal is to let 69.0 reach the world via this gateway machine 68.22/69.22.
Is some iptables needed in this case?

Re: Basic routing

[Thomas Bätzler]

Hi,

Am 04.10.2014 um 13:06 schrieb John Smithee:
> Ok, I admit using "ping -I" was a bad example. The whole point I tried
> to make is, that the second net (69.0) cannot reach any other IP
> outside its own net.
> The goal is to let 69.0 reach the world via this gateway machine
> 68.22/69.22.
> Is some iptables needed in this case?

You do have IP forwarding enabled?

If not,  enable it using
  echo "1" > /proc/sys/net/ipv4/ip_forward
and try again.


HTH,
Thomas

-- 
BRINGE Informationstechnik GmbH
Zur Seeplatte 12
D-76228 Karlsruhe
Germany

Fon: +49 721 94246-0
Fon: +49 171 5438457
Fax: +49 721 94246-66
Web: http://www.bringe.de/

Geschäftsführer: Dipl.-Ing. (FH) Martin Bringe
Ust.Id: DE812936645, HRB 108943 Mannheim


---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com

Re: Basic routing

[John Smithee]

Thomas Bätzler wrote, On 10/04/2014 03:56 PM:
> Hi,
>
> Am 04.10.2014 um 13:06 schrieb John Smithee:
>> Ok, I admit using "ping -I" was a bad example. The whole point I tried
>> to make is, that the second net (69.0) cannot reach any other IP
>> outside its own net.
>> The goal is to let 69.0 reach the world via this gateway machine
>> 68.22/69.22.
>> Is some iptables needed in this case?
>
> You do have IP forwarding enabled?
>
> If not,  enable it using
>    echo "1" > /proc/sys/net/ipv4/ip_forward
> and try again.
>
>
> HTH,
> Thomas


Yes, ip frowarding is enabled.

After doing much research on the net and experimenting
I think (still testing) I finally found a solution,
but it's unfortunately a little bit complicated.
I'll summarize later.

Re: Basic routing

[John Smithee]

John Smithee wrote, On 10/04/2014 05:07 PM:
> Thomas Bätzler wrote, On 10/04/2014 03:56 PM:
>> Hi,
>>
>> Am 04.10.2014 um 13:06 schrieb John Smithee:
>>> Ok, I admit using "ping -I" was a bad example. The whole point I tried
>>> to make is, that the second net (69.0) cannot reach any other IP
>>> outside its own net.
>>> The goal is to let 69.0 reach the world via this gateway machine
>>> 68.22/69.22.
>>> Is some iptables needed in this case?
>>
>> You do have IP forwarding enabled?
>>
>> If not,  enable it using
>>    echo "1" > /proc/sys/net/ipv4/ip_forward
>> and try again.
>>
>>
>> HTH,
>> Thomas
>
>
> Yes, ip frowarding is enabled.
>
> After doing much research on the net and experimenting
> I think (still testing) I finally found a solution,
> but it's unfortunately a little bit complicated.
> I'll summarize later.


I finally managed to get it working with these steps:

IF0="eth0"
NW0="192.168.68.0/24"
ET0="192.168.68.22"
GW0="192.168.68.254"
TAB0="my0"  # must be defined in /etc/iproute2/rt_tables, f.e. 100 my0

IF1="eth1"
NW1="192.168.69.0/24"
ET1="192.168.69.22"
GW1="192.168.69.7"
TAB1="my1"  # must be defined in /etc/iproute2/rt_tables, f.e. 101 my1

ip route add $NW0 dev $IF0 src $ET0 table $TAB0
ip route add default via $GW0 table $TAB0

ip route add $NW1 dev $IF1 src $ET1 table $TAB1
ip route add default via $GW1 table $TAB1

ip route add $NW0 dev $IF0 src $ET0
ip route add $NW1 dev $IF1 src $ET1

# your preference for default route:
ip route add default via $GW0

ip rule add from $ET0 table $TAB0
ip rule add from $ET1 table $TAB1
ip rule add to   $ET0 table $TAB0
ip rule add to   $ET1 table $TAB1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


This solution is not that bad, though IMHO complicated.
But one thing is still missing: 69.* cannot ping
the IP 68.22, but other than that it can reach everything else.

If someone knows a simpler solution pls let me know, thx.


Here are some references where I found the above stuff:

http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/
http://www.linuxhorizon.ro/iproute2.html
http://www.lartc.org/howto/lartc.rpdb.html
http://www.lartc.org/howto/lartc.rpdb.multiple-links.html

Re: Basic routing

[John Lister]

On 04/10/2014 18:44, John Smithee wrote:
> John Smithee wrote, On 10/04/2014 05:07 PM:
>> Thomas Bätzler wrote, On 10/04/2014 03:56 PM:
>>> Hi,
>>>
>>> Am 04.10.2014 um 13:06 schrieb John Smithee:
>>>> Ok, I admit using "ping -I" was a bad example. The whole point I tried
>>>> to make is, that the second net (69.0) cannot reach any other IP
>>>> outside its own net.
>>>> The goal is to let 69.0 reach the world via this gateway machine
>>>> 68.22/69.22.
>>>> Is some iptables needed in this case?
>>>
>>> You do have IP forwarding enabled?
>>>
>>> If not,  enable it using
>>>    echo "1" > /proc/sys/net/ipv4/ip_forward
>>> and try again.
>>>
>>>
>>> HTH,
>>> Thomas
>>
>>
>> Yes, ip frowarding is enabled.
>>
>> After doing much research on the net and experimenting
>> I think (still testing) I finally found a solution,
>> but it's unfortunately a little bit complicated.
>> I'll summarize later.
>
>
> I finally managed to get it working with these steps:
>
> IF0="eth0"
> NW0="192.168.68.0/24"
> ET0="192.168.68.22"
> GW0="192.168.68.254"
> TAB0="my0"  # must be defined in /etc/iproute2/rt_tables, f.e. 100 my0
>
> IF1="eth1"
> NW1="192.168.69.0/24"
> ET1="192.168.69.22"
> GW1="192.168.69.7"
> TAB1="my1"  # must be defined in /etc/iproute2/rt_tables, f.e. 101 my1
>
> ip route add $NW0 dev $IF0 src $ET0 table $TAB0
> ip route add default via $GW0 table $TAB0
>
> ip route add $NW1 dev $IF1 src $ET1 table $TAB1
> ip route add default via $GW1 table $TAB1
>
> ip route add $NW0 dev $IF0 src $ET0
> ip route add $NW1 dev $IF1 src $ET1
>
> # your preference for default route:
> ip route add default via $GW0
>
> ip rule add from $ET0 table $TAB0
> ip rule add from $ET1 table $TAB1
> ip rule add to   $ET0 table $TAB0
> ip rule add to   $ET1 table $TAB1
>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
>
> This solution is not that bad, though IMHO complicated.
> But one thing is still missing: 69.* cannot ping
> the IP 68.22, but other than that it can reach everything else.
>
> If someone knows a simpler solution pls let me know, thx.
>
>
> Here are some references where I found the above stuff:
>
> http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ 
>
> http://www.linuxhorizon.ro/iproute2.html
> http://www.lartc.org/howto/lartc.rpdb.html
> http://www.lartc.org/howto/lartc.rpdb.multiple-links.html
>

This seems overly complicated for what sounds like a simple routing 
solution. I'm guessing there must be something slightly out of the 
ordinary about your setup or I'm mising something. I'm assuming 
something like this


MACHINE1-x.69.7  ---->  .69.22 - MACHINE2 - .68.22 ----> .68.254 - 
DEFAULT ROUTER --> internet


the routing table for machine1 should be
default 192.168.69.22 0.0.0.0 eth0
192.168.69.0 * 255.255.255.0 eth0

and for machine2 is should be
default 192.168.68.254 0.0.0.0 eth0
192.168.68.0 * 255.255.255.0 eth0
192.168.69.0 * 255.255.255.0 eth1


The only issue you have is that there either needs to be a route on your 
external router to 192.68.69.0/24 via 192.168.68.22 or as you have it 
above an iptables rule to masquerade any address on the 192.168.69 
domain to the eth0 address so that the replies from outside your network 
know how to get back to your private subnet.

John

>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Basic routing

[André Paulsberg]

: If someone knows a simpler solution pls let me know, thx.

SHORT answer , I think you forgot return routing !
I am not sure what you are doing here , but I am sure from your last post you are "doin' it wrong" .
If I understand your solution , you have now "eliminated the need" for routing by using NAT !

Since I cannot see your complete setup I will explain some BASIC "issues" you might encounter .
( And I believe this might be your issue for this case too ) 


NET A  --- A side GW-X (ROUTER) B side GW-X --- NET B  --- B side GW-Y (ROUTER) C side GW-Y  --- Internet/or further networks
SWITCH                                          SWITCH  
  |                                               |
PC-A1                                           PC-B1
PC-A2                                           PC-B2


To start on the solution , the first thing we focus on is ROUTING is always 2 ways .
In any setup like above , making a route from GW-X is useless ,
unless all units "after" GW-X know a route back to side A for the NET A .

When GW's already have routing enabled , they normally only have 1 route entry added .
This is default GW going towards outside world , additionally they also have automatic
"routing" for all local interfaces .
When you have this traffic will only go from "left to right" , meaning when you send packets from
A to B , the B will send any reply out to C , because it will follow default route going "right" .
MINIMUM to solve this is to make a route for NET A on GW-Y to GW-X .

Now A will send to B and B return packets to A through GW-Y router ,
this is somewhat suboptimal since only unit on NET B with route to A IS GW-Y .
( meaning all traffic to NET A must initially go through GW-Y , making an extra HOP for PC's in NET B )
Next step is to solve this by either adding a route for all units , here seen as PC-B1 and PC-B2 ,
So that they send traffic directly to GW-X for NET-A and have default route to GW-Y .
( This can also be done via routing protocols like RIP , OSPF or IS-IS , but for home use you will likely add one more route )

Your next issue will be fix RFC1918 ( private address space ) when going to Internet ( or any other outside network )
This is usually fixed by adding NAT for all networks to the address of GW-Y's IP on NET C when leaving GW-Y towards outside .
This must include in this examples NET A and NET B , if not no one on the outside will be able to return packets 
( this also means that GW-Y IP on NET C needs to be public and also routed , which is normaly the responsibility of your ISP )


Hope this explains how to start your setup from scratch again , if not please ask if you need more info .


Best regards
André Paulsberg
Senior Network Engineer 
Core Network
Operation, Network, Nordic Operations
andre.paulsberg@evry.com
M +47 9070 5988