|
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
<web400@xxxxxxxxxxxx>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
inTo 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
message news:brdbpp$mr$1@xxxxxxxxxxxxxxxx
Greetings list!webserver
I am attempting to forward HTTP requests from one iSeries Apache
=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.
_______________________________________________ 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.
midrange.com
