Kirk -

Thanks for your help.

Yes, the netmask for both is 255.255.255.0.  Since I am in a departmental IT
group, I have no control over the corporate network topology - IOW, I have
no ability or authority to change subnets or reassign default gateways.

We have another test system which is on a separate segment (IP addr
172.17.26.48).  I tried using it as the front-end, pointed to 10.10.18.54
but got the same results.  Is this due to your
statement -
> If you decide to change the network address to 10.10.19.x then ALL devices
> in the 10.10.18.x network must have their default gateways pointing to the
> 400 at 10.10.18.25.
????

Thanks,

Steve



<kirkg@xxxxxxxxxxxxx> wrote in message
news:OF5BCA95B8.F4798FC5-ON88256DFF.0051B683-88256DFF.00546D7B@xxxxxxxxxxxxxxxx
> I think your problem is in the basics of how IP works. Without seeing the
> netmask, I'm betting both of these IPs are most likely subnet,
> 255.255.255.0. If that is true, then no routing or filtering can take
> place the way you want.
>
> Think of it has everyone on 10.10.18.x being on a party line, everyone
> here's everyone else. You tell George(10.10.18.25) to not let
> John(10.10.18.54) hear or say something. For your filtering to work a few
> things must happen. These must be thought out before you start actually
> doing any of this since I don't anything about your network.
>
> Logically you must seperate 10.10.18.25 and .54 on to seperate networks.
>
> If the number of devices are small you could change the netmask to say
> 255.255.255.224. This would create  8 32 address networks
> 1-31, 32-63, 64-95 etc. If you need more than that then you will need to
> change the subnet itself to say 10.10.19.x for the .54 address.
>
> If you decide to change the network address to 10.10.19.x then ALL devices
> in the 10.10.18.x network must have their default gateways pointing to the
> 400 at 10.10.18.25.
>
> There is more to this than above but's it's the basics. The main thing is
> the packets can't have a way around whatever is filtering. To get from .25
> to .54 and get filtered, they must be on different networks.
>
>
> _____________________
> Kirk Goins CCNA
> Systems Engineer, Manage Inc.
> IBM Certified iSeries Solutions Expert
> IBM Certified iSeries e-Business Infrastructure
> IBM Certified Designing IBM e-business Solutions
> Office 503-353-1721 x106 Cell 503-577-9519
> kirkg@xxxxxxxxxxxxx      www.manageinc.com
>
>
>
> "Steve McKay" <steve.mckay@xxxxxxxxxxxxxx>
> Sent by: web400-bounces@xxxxxxxxxxxx
> 12/17/2003 06:19 AM
> Please respond to
> Web Enabling the AS400 / iSeries
<web400@xxxxxxxxxxxx>
>
>
> To
> web400@xxxxxxxxxxxx
> cc
>
> Subject
> [WEB400] Re: IP filtering
>
>
>
>
>
>
> Further information -
>
> If 10.10.18.25 and 10.10.18.54 are both defined interfaces on a single
> iSeries, the filter rules work fine.  Unfortunately, this is not what I
> need
> to do - I need to use one system as a "traffic cop" to redirect requests
> to
> a second system.
>
> If 10.10.18.25 and 10.10.18.54 are on separate systems, the same filter
> rules as above do not work.  I can only conclude that, when the IP filter
> rules change the IP address in the packet, the packet does not get put
> back
> out on the network.
>
> Can anyone confirm or deny this?
>
> Thanks,
>
> Steve
> "Steve McKay" <steve.mckay@xxxxxxxxxxxxxx> wrote
in
> message news:brdbpp$mr$1@xxxxxxxxxxxxxxxx
> > Greetings list!
> >
> > I am attempting to forward HTTP requests from one iSeries Apache
> webserver
> > to another on a private network (not VPN, just a non-Internet Ethernet
> > network).  I have created the following IP packet rules:
> >
> > ADDRESS frontend   IP = 10.10.18.25   TYPE = BORDER
> > ADDRESS backend   IP = 10.10.18.54   TYPE = TRUSTED
> > HIDE backend:80   BEHIND frontend:80   TIMEOUT = 16   MAXCON = 512   JRN
> =
> > OFF
> >
> > When I activate the rules and point the browser to 10.10.18.25, I get a
> > "Cannot find server or DNS error" message but if I go directly to
> > 10.10.18.54, I get the expected website.
> >
> > Any ideas?
> >
> >
> >
> > _______________________________________________
> > This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> > To post a message email: WEB400@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/web400
> > or email: WEB400-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/web400.
> >
> >
>
>
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>
>




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2022 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.