Date: Sun, 28 Sep 1997 08:52:16 -0400 (EDT) From: Brian Clapper <bmc@WillsCreek.COM> To: questions@FreeBSD.ORG Subject: Re: How to Route to server?? Message-ID: <199709281252.IAA12619@current.willscreek.com> In-Reply-To: <132809681@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
bsd@[203.56.101.65] wrote:
> I have a work around now...I have a dynamic IP dialin to my ISP from
> my fbsd gateway machine and so I have changed all the LAN NIC IPs to
> the 192.168.0.0 c block. I can now go out from any machine via the
> gateway box through the ISP to my remote server (and its LAN) which
> is a static IP system (same class c block I originally had my problem
> gateway LAN configured as)
...
> Here is the set up.....
>
> Basically I want both my LANS to connect via ISP (at the moment)
>
> mickey (192.168.0.s) gatewaybsd(192.168.0.x).....more boxes
> ..... | .................... ................... |..........
> |
> ISP--- rest of Internet
> |
> My remote Server bsd box (xx.xx.xx.xx)
> |
> LAN machines(xx.xx.xx.yy)___ | ____ LAN machines(more)
>
> Eventually I wish to set up My remote Server bsd box to accept a
> static IP dialin from my "gateway" LAN directly...not via ISP
> But that's a lot of homework later!
>
> Hope you can help...I am not in love with the 192.168.0.x solution
> because I have the class c block & I eventually want to direct dial
> in.
> Thanks
You describe your ideal setup like this:
LAN 1
-------------------------------------------------------------------
| | |
mickey gatewaybsd other boxen
|
/
\
\ PPP connection
/
|
remote server
LAN 2 |
-------------------------------------------------------------------
| |
machine X more boxen
The problem is that no matter how you slice it, your local network (the one
with `gatewaybsd' on it) and your remote network have to be configured as
different networks. IP uses the network ID of an outbound packet to tell
whether it should send the packet directly to the host or route it via
another host. Essentially, if the destination network number matches the
network number one of the machine interfaces, the IP code assumes the
target machine is directly reachable. If you simply use numbers out of
your class C for both LANs, when `mickey' attempts to send to `machine X',
it'll find out that `machine X' has the same network number, and attempt to
send the packet directly. When it gets no reply to its ARP query, `mickey'
will inform you that the host is down (which, I believe, is the symptom you
were seeing).
For each machine on LAN 1 to be able to reach each machine on LAN 2, and
vice versa, the LANs must be on different subnets. Plus, you have to treat
the PPP connection as a third subet, one that connects the two gateways.
There are a number of ways to go here. For example, you could use RFC 1918
address behind the gateways, and have the gateways do network address
translation to map the "illegal" RFC 1918 numbers into your class C range.
(This works fine, BTW; I use it at home.) Alternatively, you could use RFC
1918 numbers on only one LAN, and assign numbers out of your class C to the
other LAN; in that case, you'd use RFC 1918 numbers on whatever LAN doesn't
dial up to the ISP, just for simplicitly. Or, you could simply assign
numbers out of your class C range to all machines on both networks.
The latter case seems to be what you want. To do that, you're going to
have to subnet your class C address space. Since you need three subnets,
you must steal two bits from the host portion and assign it to the network
portion. (You'll get four subets out of that deal, wasting one, but that
can't be helped.) This means you'll use a netmask of 255.255.255.192
(0xffffffc0, or 11111111.11111111.11111111.11000000 binary) for all hosts
on all the subnets you control.
That gives you four subnets, one for each combination of the two extra bits:
STOLEN HOST FIRST LEGAL LAST LEGAL
BITS VALUE IP ADDRESS IP ADDRESS
--------------------------------------------------
00 x.y.z.1 x.y.z.62
01 x.y.z.65 x.y.z.126
10 x.y.z.129 x.y.z.190
11 x.y.z.193 x.y.z.254
--------------------------------------------------
You lose a few addresses, because you can't have a 6-bit host portion
consisting of all 0s or all 1s on any of the subnets. (A host portion of
all 0s is reserved for machines on the subnet that don't know their IP
numbers. A host portion of all 1s is the subnet's broadcast address.) But
you're left with 62 possible hosts per subnet.
Now map those network numbers to each subnet:
LAN 1 (subnet 00)
-------------------------------------------------------------------
| x.y.z.2 | x.y.z.1 | x.y.z.{3-62}
mickey gatewaybsd other boxen
| x.y.z.65
/
\
\ PPP connection (subnet 01)
/
| x.y.z.66
remote server
LAN 2 (subnet 10) | x.y.z.129
-------------------------------------------------------------------
| x.y.z.130 | x.y.x.{131-190}
machine X more boxen
Make sure that the netmasks on all machines are 255.255.255.192, so the
various systems know how to route properly.
When your remote server and `gatewaybsd' machine are connected, they
should communicate just fine; just make sure you get the near-end and
far-end of the respective PPP connections correct.
When your `gatewaybsd' box dials up to the ISP, you'll need to ensure that
the address assigned to the far end of the PPP link is either (a) on your
`11' subnet or (b) is on a different class C network entirely. You'll
probably need different configuration files to dial up the ISP versus
dialing up your other network.
This scenario should work just fine for you. It's a little annoying to
subnet a class C, only because you're fiddling with a netmask that creeps
into the last octet; that can make it difficult to remember which network a
host maps to, when the numbers are expressed in decimal. You'll get used
to that soon enough, though.
-----
Brian Clapper, bmc@WillsCreek.COM, http://WWW.WillsCreek.COM/
Numeric stability is probably not all that important when you're guessing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709281252.IAA12619>