Tweet
(Moved to the correct forum) Okay, folks. Here's a weird one. I've got an AS/400 sitting behind a router. The router performs NAT for me, but also does some port forwarding if I ask it nicely. For example, requests to my realworld IP address on port 25 go to my Linux machine, which has an internal address. I have a Linux box, a W2K workstation and an AS/400, all sitting behind a router. Let's say my addresses look like this: Realworld IP: 63.64.65.66 Router: 10.10.10.101 Linux: 10.10.10.102 AS/400: 10.10.10.103 W2K WS: 10.10.10.104 Now, if I forward port 80 to the Linux box it works just fine. I do an HTTP GET to my realworld IP, and up comes the welcome page from my Linux machine. This is way cool. However, I can't seem to get it to map to the AS/400. I can access the AS/400's HTTP server INTERNALLY just fine, by using my 10. addressing. But it won't listen to the mapped request. So I did a little sniffing, and found out something interesting. When my W2K machine makes a request using the realworld IP, the following occurs on my network: 10.10.10.104 --> 63.64.65.66 (initial request) 63.64.65.66 --> 10.10.10.102 (request forwarded to Linux box!) 10.10.10.102 --> 63.64.65.66 (response from Linux box to router) 63.64.65.66 --> 10.10.10.104 (response finally returned to me) Notice how the router handles the port forwarding... it sends a request to the destination device, but only after spoofing the source address to be the realworld address of the router! I don't have the time to sit and think it through; I'd think you would just leave the real source address in place, or else pass the WAN address of the router (not the realworld address). I tried picturing the possible combinations of multiple requests forwarded to multiple devices through multiple IP addresses, and I started to get ill. And regardless of the WHY, this is how it works. So, rather than try to figure it out, I decided to go the next step. And that next step is to try and figure out why the AS/400 wasn't responding. And pure and simple, the AS/400 was ignoring those packets. Here's the trace: 10.10.10.104 --> 63.64.65.66 (initial request) 63.64.65.66 --> 10.10.10.103 (request forwarded to AS/400) (delay) 10.10.10.104 --> 63.64.65.66 (initial request) 63.64.65.66 --> 10.10.10.103 (request forwarded to AS/400) (delay) That goes on until the browser times out. Remember, communications work fine on the intranet, and if I watch the communications, it's fine: 10.10.10.104 --> 10.10.10.102 (request) 10.10.10.102 --> 10.10.10.104 (response) So, the issue seems to be that the AS/400 doesn't want to communicate with the external address. Now, where in the world is this configured? Due to a different problem (which I'll outline when I get a chance), I did a RMVTCPTBL TBL(*ALL), so that should have gotten rid of any latent IP filtering. So where else is IP filtering defined? In the HTTP configuration? In the line description? WHERE??!?!?!? Thanks a million for listening to the frustrations of a beaten man... . Joe
-
-
Wit's End with IP Filtering
Problem solved... since my router is spoofing an external address, I had to add a *DFTROUTE entry to my AS/400 to tell it how to handle external addresses. One more bit added to the teetering tower that represents my comms knowledge. -
Wit's End with IP Filtering
I am not clear on your question. Are the two cards on different networks? What is the IP address and mask of each card?Comment
-
Wit's End with IP Filtering
Guess what? The *DFTROUTE only allows me to access the AS/400 within my network. But when I try to access it from OUTSIDE the router, it still doesn't work. And then I tried to PING an outside system, and THAT doesn't work. For some reason, the *DFTROUTE is not enough to get me through my router and out to the real world. Here's what I have:Route Subnet Next Preferred Opt Destination Mask Hop Interface *DFTROUTE *NONE 10.1.1.17 *NONE
And no joy. I can't get PING to access anybody outside of my network. What am I doing wrong? (If I remove the *DFTROUTE, I get "Cannot reach remote system", and if I have the *DFTROUTE in place, I get "No response from host".) JoeComment
-
Wit's End with IP Filtering
Thought I'd review all my travails, and post the stuff I've been posting on MIDRANGE-L. Please be advised this is four posts, some a bit long-winded (who, me?) although they get shorter and shorter as time wears on. But anybody willing to wade through these and see if they can spot something, I'd appreciate it: ------------ 9:28PM Sorry folks. I'll try to give complete information this time. My AS/400 has an address of 10.1.1.60. My workstation is 10.1.1.20, my NT server 10.1.1.100 and my router 10.1.1.17. My Linux machine is 10.1.1.70. My router is a Netopia, and it happily allows all of my devices to communicate with the external world through my DSL line. All that is, except for the AS/400. Now to answer some of your specific questions: "1. Can you ping your router from your AS/400 and from your NT Machines?" Yes. All machines ping one another quite nicely. The AS/400 actually serves web pages quite well within the LAN. "2. What is the internal IP address of your AS/400 and what is the subnet that you are using?" As I said, the internal address is 10.1.1.60. The subnet I use on each of the machines is 255.255.255.0. "3. Are you pinging by IP Address or domain name?" IP address. Since the AS/400 cannot get out to the real world, its cannot access DNS servers either. So I am attempting to ping *INTNETADR, and this is failing as well. "You also said that you are trying to do webserving with your AS/400. Is this internal or external? If external, you will need to have your firewall or router convert your external address to your internal address. Can you ping the AS/400 from your NT? DId you start the webserver on the AS/400? You can start the admin server and try to connect to it.. http://ipaddress:2001/ to see if it is working." This is exactly what I am trying to do, but it is not working. I use my router to map address for port 80 to my AS/400 (address 10.1.1.60), and it doesn't work (although the AS/400 is serving pages internally perfectly). I change the router to map port 80 to address 10.1.1.100 (the NT server) and it works - the copy of WebSphere running on the NT server serves up pages perfectly. So the AS/400 is doing something differently than the NT server. Now, on the NT server I have to set my gateway to 10.1.1.17. On the AS/400, there is something called the default route, which I've also set to 10.1.1.17. Once I did that, the AS/400 was able to communicate inside the LAN, but it still will not send packets past the router. Here's the interesting bit: With the Netopia configured to pass port 80 to 10.1.1.60: 1. Inside the LAN, a request to 10.1.1.60:80 gets pages from the AS/400. 2. Inside the LAN, a request to 216.36.82.12:80 (the router's realworld address), gets pages from the AS/400. 3. Requests from outside the LAN to 216.36.82.12:80 get no response. With the Netopia configured to pass port 80 to 10.1.1.100: 1. Inside the LAN, a request to 10.1.1.60:80 gets pages from the AS/400. 2. Inside the LAN, a request to 216.36.82.12:80 (the router's realworld address), gets pages from the NT server. 3. Requests from outside the LAN to 216.36.82.12:80 get pages from the NT server. " Your 10.1.1.* address needs a router or firewall or some means of being "routed" or "natted" to an external public address. Normally ( is there such a thing ) you would have all of your private addresses inside of a firewall. Your firewall might translate, via NAT, your 10. private address to an external and public address. Your router may also perform this function." This is what the Netopia is doing. I followed the instructions on the Netopia site, and as I've explained, it works perfectly for the NT server. It's just not passing the data from the AS/400. Is it something to do with IP forwarding or one of those other arcane TCP/IP switch settings? "Do you know how to run a comm trace on your AS/400? Do you have one of the downloadable TRACERT utilities for the AS/400? Is your one and only route active? A process called dead gateway processing will make your route inactive for a period of time if your next hop cannot be pinged by the AS/400." No, no, yes. I did the NETSTAT, and it shows this: Route Subnet Next Route Opt Destination Mask Hop Available 10.1.1.0 255.255.255.0 *DIRECT *YES 127.0.0.0 255.0.0.0 *DIRECT *YES 224.0.0.0 240.0.0.0 *DIRECT *YES 224.0.0.0 240.0.0.0 *DIRECT *YES *DFTROUTE *NONE 10.1.1.17 *YES Not sure about the 224.0.0.0/240.0.0.0 entries - there's one for 10.1.1.60 and one for 127.0.0.1. The interesting thing is it's now taking a long time to do an option 5 on those routes - a do an option 5 and NETSTAT goes into SELW for about 30 or 40 seconds (it wasn't doing this before). Next thing is, I'm going to shut down TCP/IP and bring it back up again. I hate doing this, because I inevitably screw up the servers and then nothing works. But I'm going to give it a shot. I'll also look into getting a TRACERT utility from somewhere. I saw something about it, can't remember where. --------------- 9:43PM Did the tracert thing. Worked on 10.1.1.20, didn't go anywhere on an external address. traceroute to 10.1.1.20 (10.1.1.20), 30 hops max, 40 byte packets 1 PBDWS1 (10.1.1.20) 14.232 ms 1.456 ms 1.264 ms Press ENTER to end terminal session. traceroute to 63.167.147.106 (63.167.147.106), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * ===> F3=Exit F4=End of File F6=Print F9=Retrieve F17=Top F18=Bottom F19=Left F20=Right F21=User Window Ad nauseum. ---------------- 9:57PM And just to clarify - the AS/400 successfully pings 10.1.1.17 (the internal address of the router). The AS/400 can in fact ping ANY of the machines on the internal network. It simply cannot ping anything past the router. All other machines on the network, however, can indeed ping inside and outside the network (including pinging the AS/400). The AS/400 cannot even ping the realworld address of the router. All the other machines do, with under 10msec response time (on the other hand, pinging a realworld address other than the router is on the order of 100 msec). It seems to me that the AS/400 is simply not sending out any packets to addresses other than itself. Now to grab a sniffer and see if that helps anything. ----------- 10:47PM Final piece to the puzzle. When I put up a sniffer, the AS/400 doesn't even make a peep on the network during the ping. When I ping internally, I see two ARP broadcast packets from what I assume is my AS/400, followed by a response from what I assume is my router. After that, there are a bunch of ICMP echos and replies. When I ping an unconfigured address in the net, there are a whole bunch of ARP broadcasts, but of course no replies. And when I ping an address NOT in the subnet, there isn't even a peep on the ether - not even an ARP broadcast. So how about THEM apples, eh? ------------ That's it. I've tried everything. Can't figure out why the AS/400 refuses to talk outside of its net. It talks inside fine, just not outside. It's as if it's been told not to talk to strangers, I don't know. JoeComment
-
Wit's End with IP Filtering
Joe, Do you have a firewall? DaveComment
-
Wit's End with IP Filtering
"Do you have a firewall?" No.Comment
-
Wit's End with IP Filtering
This sounds to me like an IP filter is set to block traffic to and from the IP of your AS/400. Were you playing with IP filtering on your Netopia router at some point? It may not be precisely true that you don't have a firewall. The Netopia routers I checked into had pretty decent firewall features built in.Comment
-
Wit's End with IP Filtering
Since the thread's title denotes IP Filtering, you may look at my last post and say Duh? It's just that I think of address and port mapping as one thing, and IP filtering as another. Address and port mapping pertains to configuration elements used to enable communication. Filtering pertains to configuration elements used to disable communication. For example, when you use the TCPADM menu to define port restrictions, that's filtering. When you define a default route, that's mapping.Comment
-
Wit's End with IP Filtering
I had a similar problem getting past routers to remote segments of our network. I added a specific route to the taple (CFGTCP , #2) that looks like this: Route destination . . . . . . . . . . : 172.29.0.0 Subnet mask . . . . . . . . . . . . . : 255.255.0.0 Type of service . . . . . . . . . . . : *NORMAL Next hop . . . . . . . . . . . . . . . : 172.29.0.6 Preferred binding interface . . . . . : *NONE Maximum transmission unit . . . . . . : 576 Duplicate route priority . . . . . . . : 5 Route metric . . . . . . . . . . . . . : 1 Route redistribution . . . . . . . . . : *NO and I removed all references to a default route. Hope this helpsComment
-
Wit's End with IP Filtering
I'm not sure if this problem has been solved by now but just in case it seems like you need another route entry: Rte Dest Subnet Next Hop *DFTROUTE *NONE 216.36.82.12Comment
Comment