× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for your comments, Scott. Sometimes my words, in
haste, don't say exactly what I mean. This is helping
me - I hope these exchanges help others, too.

Re-responses in line---

At 07:53 AM 7/17/2002 -0500, you wrote:


On Tue, 16 Jul 2002, Vernon Hamberg wrote:
>
> Hmm, I'm getting a question---what if you want to
allow access to 2
> servers, both with the same protocol(s)? If you have
NAT, you don't give
> them your internal address, do you? I mean, those are
often blocked out in
> the big bad Internet, I believe.

A private ("internal") address cannot be routed from the
Internet.  It's
not because they're "blocked out."  (Not in the sense
that a firewall
blocks an IP, anyway) rather they're reserved for use in
private networks,
and therefore none of the routing tables on the internet
backbone have
routes assigned for them.

Many companies are using those same exact internal IPs
on their intranets,
so they're not unique and cannot be resolved to a single
machine.

Yeah, that's what I meant - these addresses are unusable
on the big-I Internet. Blocked wasn't the right
expression - not even on the horizon is better, right?

>
> And you don't have the luxury of setting up gateways
(routes) based on
> destination and subnet, as we do on the 400.
>

If you can't set up routines based on destination and
subnet, you're not
using TCP/IP.  IP addresses, subnet masks, destinations
and gateways are
the core of the protocol.

I've only set up routes on the 400 and gateways in
various flavors of Windows. On the 400 you can specify a
certain "destination" subnet (net address & mask) that
will use a certain "next hop" -- as you know. I've never
seen this in Windows - of course, I've also not needed
it. Is it there? I just looked at XP - only the gateway
(next hop) address can be specified - nothing about the
destination subnet is listed there.

> This is similar to something I'm trying to do at work.
(Yes, we have to do
> it more securely - someday!) But I have an iSeries
with a public address
> (mask of 255.255.255.248 from our ISP) that is our
development box. This
> subnet is connected to our intranet with a LinkSys
router. All developers
> are behind the NAT function of this router. I've set
up forwarding for port
> 4200 (STRCODE's default) to my PC. Will I muck things
up by having
> additional entries on the same port but to different
machines?

If you have a netmask of 255.255.255.248, that means
that you've got
6 public IP addresses.  Since one of them is probably
assigned to your
router, you still have 5 public addresses that you can
use.

Therefore, you can have the same port mapped to 5
different machines
without causing problems. (one for each address)
Assuming, of course,
that your router supports it.

My company does exactly this.  We've got 5 public
addresses, and NAT is
set up to route each address to a different internal
server.  We can have
as many machines as we like doing outgoing connections
as we like, but
we can only run the same service (server-side) on 5
different machines...

The forwarding that the LinkSys router has is based only
on ports, not public addresses. So if I set up port 4200
to go to 2 different addresses, I'm wondering whether it
will work, or get confused. Of course, we could use a
different port for each evocation of STRCODE.

> I have a
> route on the 400 for 192.168.0.0 mask 255.255.255.0
with next hop being the
> side of the router that is on the same subnet as the
400. BTW, the default
> route for the 400 goes through the DSL modem.

Isn't 192.168.0.0 your LAN?   Unless you've got that
divided into multiple
subnets, you shouldn't need a route.  Your local LAN
will be routed
automatically, it will only forward to your router if
the dest IP is not
within the netmask of your ethernet adapter.

It appears I did not need that route. It is no longer on
the 400, and I think someone may have removed it. Or
would it just have got rolled up into *DFTROUTE
automagically? I was not sure, and wanted to explicitly
direct things through the LinkSys. The 400 has an
address of x.x.x.211, with next hop of x.x.x.214, which
is the address on the inside of the DSL modem. That gets
us out the subnet assigned by our ISP.

The LinkSys has an address of x.x.x.213 on the same
subnet as the 400 and the DSL modem. The other side of
the LinkSys is the 192.168.0.x subnet.

>
> I suspect we really need a more robust, flexible
firewall/proxy/NAT to
> do what we want (I show some of my ignorance there
<g>).
>

Each TCP/IP packet contains a dest addr, dest port and a
source addr and a
source port. You can't really control the source addr &
port, since that's
the machine it's coming from, and needs to be the same
in order for system
to send packets back. So, really all it has to go on is
the dest
address & port.  Doesn't matter how "robust" the router
is, it needs to be
able to forward the packet based on that information
alone.

You see what I'm saying?  The destination address & port
combination has
to be mapped to a single place...

Yeah, right. What I meant was something that had more
flexibility, I guess. The LinkSys makes no claims at
being a full-feature firewall, and we will soon run out
of entries in the forwarding table. So far we are small,
but things grow.

Thanks muchly.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.