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