netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Basic Routing
Date: Mon, 20 Sep 2010 22:34:10 -0500	[thread overview]
Message-ID: <4C9827B2.3040406@riverviewtech.net> (raw)
In-Reply-To: <4C97D4B6.2000609@amfes.com>

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

  parent reply	other threads:[~2010-09-21  3:34 UTC|newest]

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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=4C9827B2.3040406@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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