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

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.