|
Kirk - Thanks again, I'm going to be out until after the 1st myself . . . The question occurs to me - Can it be done? Can I use IP filtering on system A to re-direct an HTTP request to System B and then send System B's response back to the original requestor? I'm beginning to wonder . . . Thanks, Steve "Kirk Goins" <kgoins@xxxxxxxxxxx> wrote in message news:3FE3EA2E.2070703@xxxxxxxxxxxxxx > I can think of a couple of things: > #1 If you are on 5.1 or better on the 400s try the traceroute cmd 1st > from .111 to .48 and then from the test 400 to .54 > that cmd supports telling it what out going IP to use. So on > test try it once on .48 and then on the other IP > > #2 Double check the routing statements on the test 400 (cfgtcp then #2) > using the rules of how IP routes see where a 10.x.x.x should go > > #3 try using comm trace "strcmntrc" on the test 400 to see if if > actually leaving the box. > > I'm going to be traveling on business Sunday-Wednesday so It will be > evenings before I'll be able to get back to you. > > Steve McKay wrote: > > >BTW - > > > >I turned on IP filter journalling and there are 3 identical journal entries > >generated when I try to get to 172.17.26.48:80 . . . they look like this: > > > >ETHLINE A I 3 610.10.18.111 1885172.17.26.48 8010.10.18.111 > >188510.10.18.54 80 > > > >This appears (to me) to indicate that the AS/400 at 172.17.26.48 is > >receiving the packet from my PC at 10.10.18.111 and attempting to forward it > >to 10.10.18.54 but it isn't getting there for some reason. > > > >Unfortunately, the InfoCenter link for journal code M, type TN points to the > >"TCP/IP Configuration and Reference" manual - which doesn't contain a > >*THING* about journal entries! Wonderful! > > > >Thanks again, > > > >Steve > > > >"Steve McKay" <steve.mckay@xxxxxxxxxxxxxx> wrote in > >message news:brvopc$n6q$1@xxxxxxxxxxxxxxxx > > > > > >>Yep - clear as mud - so can you help me here? > >> > >>1. From my PC at 10.10.18.111, I point my browser at 172.17.26.48 port 80. > >> > >>2. My request is examined by TCP/IP and it is determined to be destined > >> > >> > >for > > > > > >>another subnet so it is sent to the router at 10.10.18.1 (all routers on > >> > >> > >our > > > > > >>network = 1 in the 4th octet). > >> > >>3. My request leaves the 10.10.18.1 router and goes along on the network > >>until it hits the 172.17.26.1 router. > >> > >>4. The 172.17.26.1 router examines my request and "pushes" it to the test > >>AS/400 at 172.17.26.48. When the request hits the test /400, the IP > >> > >> > >packet > > > > > >>rules kick in: > >> > >>ADDRESS frontend IP = 172.17.26.48 TYPE = BORDER > >>ADDRESS backend IP = 10.10.18.54 TYPE = TRUSTED > >>HIDE backend:80 BEHIND frontend:80 TIMEOUT = 16 MAXCON = 512 JRN = > >>OFF > >> > >>Since 172.17.26.48 port 80 is "hiding" 10.10.18.54 port 80, I would expect > >>the test /400 to re-direct my packet back to 10.10.18.54. (This is the > >> > >> > >part > > > > > >>that I don't understand . . . why isn't the packet "forwarded" to > >>10.10.18.54 port 80 at this point?) > >> > >>I'm sure you've spent more time than you wanted on this but I sure > >>appreciate your help! > >> > >>Thanks, > >> > >>Steve > >> > >> > >>"Kirk Goins" <kgoins@xxxxxxxxxxx> wrote in > >>message news:3FE34A99.6040509@xxxxxxxxxxxxxx > >> > >> > >>>In short yes... > >>> > >>>IP works like this... > >>>#1The destination IP address is compared with source IP and its network > >>> > >>> > >>mask > >> > >> > >>> in your case 172.17.26.48 and 255.255.255.0 and 10.10.10.25. > >>>#2 Since 10.10.10.x isn't the same as 172.17.26.x it sends the packet > >>>to it's > >>> gateway at 172.17.26.y > >>>#3 That gateway device sends it along its way to the 10.10.10.x network > >>>#4 At the router that connects to the 10.10.10.x it looks up where > >>>10.10.10.54 is > >>> and send it directly to it (bypassing the 400) > >>> > >>>Now your 1st config with both on 10.10.10.x > >>>#1 It compares the source address 10.10.10.x with the source 10.10.10.x > >>>#2 It matched and sends the packet directly to the 10.10.10.84 not going > >>>thru the 400 again. > >>> > >>>The reason it worked when everything was on the 400, was the 400 had > >>>control of the both addresses > >>>where it does it in the 2 other cases above. > >>> > >>>Clear as mud? > >>> > >>> > >>> > >>>Steve McKay wrote: > >>> > >>> > >>> > >>>>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-Nev6iVHbUkI Q > >>VHkZcc7xNw@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. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>>_______________________________________________ > >>>>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. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>-- > >>>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 > >>> > >>>_______________________________________________ > >>>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. > > > > > > > > -- > 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 > > _______________________________________________ > 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.