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




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.