Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!
Solved
Unable to connect to AS/400 Telnet from Internet
Posted on 2004-09-10
I have an AS/400 on our internal network (192.168.2.250). I can connect to it via telnet just fine, when on the internal network, from any client. We have a DSL internet connection with a single external IP (207.x.x.x) and a Linksys router. I have forwarded TCP port 80 on the Linksys router to a Windows Web Server (internal 192.168.2.100), and it works perfectly.
I similarly want to be able to connect via telnet to the internal AS/400 from the internet. I have forwarded TCP port 23 on the Linksys router to the AS/400 (192.168.2.250), but am unable to connect. I get the message "Could not open connection to the host, on port 23: Connect Failed".
My *DFTROUTE on the AS/400 is set with the appropriate Gateway address (192.168.2.1). I do not have any other Routes specified on the AS/400. No other routing or forwarding is set up on the Linksys.
I have stopped and restarted the TCP services, checked connectivity and pings, and confirmed there are no problems with Telnet since internally it works fine. I have tried adding additional routes on the AS/400, but removed them when they did not work.
I have tried everything I can come up with to connect via telnet externally, but have been entirely unsuccessful. Any help would be greatly appreciated.
I similarly want to be able to connect via telnet to the internal AS/400 from the internet. I have forwarded TCP port 23 on the Linksys router to the AS/400 (192.168.2.250), but am unable to connect. I get the message "Could not open connection to the host, on port 23: Connect Failed".
My *DFTROUTE on the AS/400 is set with the appropriate Gateway address (192.168.2.1). I do not have any other Routes specified on the AS/400. No other routing or forwarding is set up on the Linksys.
I have stopped and restarted the TCP services, checked connectivity and pings, and confirmed there are no problems with Telnet since internally it works fine. I have tried adding additional routes on the AS/400, but removed them when they did not work.
I have tried everything I can come up with to connect via telnet externally, but have been entirely unsuccessful. Any help would be greatly appreciated.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
7-
5
-
3
- +3
21 Comments
hi,
are you connecting using plain telnet (like TN5250 or windows' telnet) or client access' telnet?
If you are using client access, port 449 also have to be "forwarded"
are you connecting using plain telnet (like TN5250 or windows' telnet) or client access' telnet?
If you are using client access, port 449 also have to be "forwarded"
As far as I know we're just using plain telnet on a 5250. I tried forwarding port 449 just in case and that made no difference. I can't telnet into port 23 or 449.
Active 2 days ago
Hey,
Lets make a test.
Enable a telnet server on a windows server or a linux server, and try to redirect the router to that server instead.
If it works - then there is something to do on the AS400.
If it does not work - then your question should be moved to the firewall or networking section.
ShalomC
Lets make a test.
Enable a telnet server on a windows server or a linux server, and try to redirect the router to that server instead.
If it works - then there is something to do on the AS400.
If it does not work - then your question should be moved to the firewall or networking section.
ShalomC
At the suggestion of shalomc, I forwarded port 23 to a WinXP machine and turned on the telnet service, and connected without a problem. I guess that rules out the ISP blocking telnet, and points to the AS400 as being the source of the problem.
i have to connect via a RAS server, to use telnet
i dial the server (an 800 number) direct
via the internet i have to use VPN, connect on the internet
then dial the VPN server
after either one connects then i open a Refelection' sessions
(green screen on a pc)
there is a way to use the ECS modem to dial in to the system
i dial the server (an 800 number) direct
via the internet i have to use VPN, connect on the internet
then dial the VPN server
after either one connects then i open a Refelection' sessions
(green screen on a pc)
there is a way to use the ECS modem to dial in to the system
Active 1 day ago
treellc:
How long has the AS/400 been in use? Are you the one who originally configured it? Have others done system configuration on it before? What model? What OS/400 version/release?
An example possibility, however unlikely, is that the internal firewall is blocking port 23. (Use OpsNav, navigate to your AS/400->Network->IP Policies->Packet Rules to begin exploring. DO NOT create and activate any rules until you fully understand the [DENY ALL] implicit rule.) It's possible that port 23 is denied if the source is outside your network.
If someone has previously configured something that's blocking, it _might_ be possible to track it down.
Tom
How long has the AS/400 been in use? Are you the one who originally configured it? Have others done system configuration on it before? What model? What OS/400 version/release?
An example possibility, however unlikely, is that the internal firewall is blocking port 23. (Use OpsNav, navigate to your AS/400->Network->IP Policies->Packet Rules to begin exploring. DO NOT create and activate any rules until you fully understand the [DENY ALL] implicit rule.) It's possible that port 23 is denied if the source is outside your network.
If someone has previously configured something that's blocking, it _might_ be possible to track it down.
Tom
Tom:
Thanks for the suggestions. As for your questions, I'm afraid I don't have all the answers since I have not been involved in the past configurations of this system, and I am fairly new to AS/400 myself. I do know it is a 5250 model that has been in use for a few years and probably a few different admins too.
My initial thought to your firewall suggestion was that if port 23 was being blocked then I shouldn't be able to log in from the local network either, but that is definitely something for me to look at. If, like you suggested, it is being denied ONLY if the source is outside our network, then that really would match the symptoms so far. Sounds like a good place for me to start looking.
I'll check into that and post back here with what I find.
Thanks for the suggestions. As for your questions, I'm afraid I don't have all the answers since I have not been involved in the past configurations of this system, and I am fairly new to AS/400 myself. I do know it is a 5250 model that has been in use for a few years and probably a few different admins too.
My initial thought to your firewall suggestion was that if port 23 was being blocked then I shouldn't be able to log in from the local network either, but that is definitely something for me to look at. If, like you suggested, it is being denied ONLY if the source is outside our network, then that really would match the symptoms so far. Sounds like a good place for me to start looking.
I'll check into that and post back here with what I find.
Active 1 day ago
treellc:
To see the model, execute:
==> dspsysval qmodel
To see the OS/400 version/release, execute:
==> dspdtaara qss1mri
The VRM will be in the first six displayed characters and will look like V4R5M0 or similar. The model and VRM will give us hints on your potential hardware and any software tools you might have.
You _could_ test whether an IP filter is active just by deactivating any current ones, but we don't know what else might be protected by them. And if we don't know what the names of your filters (if any) are nor where they might be stored, we'd have a tough time reactivating them. Note that _outbound_ packets can also be filtered by the AS/400 integrated firewall.
OTOH, packet filters can provide an additional kind of info if configured for it. Packets that arrive at the interface can also be logged for analysis. If logging is turned on for port 23, it could be a fundamental proof that telnet packets are arriving and tell what the IP source address is.
Because you can in fact telnet to your AS/400, we know the telnet server is running. (And I assume it's running on port 23.) Because you can also telnet from outside to another system on the same subnet, we can "assume" that the basic routing is okay through your ISP and router. It's _possible_ that the port forwarding was in error when pointed to the AS/400, but I imagine that was looked at closely; so we'll "assume" it was okay.
So, our assumptions say that telnet packets are arriving but the telnet server is not getting a response back out. Either the response packets are not surviving the trip or the telnet server is somehow being blocked.
If response packets are making it back out from other systems on the same subnet, we'll "assume" the telnet server is being blocked. I see two likely possibilities. First and less likely is the integrated firewall. Second and more likely, there's a telnet exit program that's rejecting the connection from an outside address. I'm sure there are more possibilities; they just don't come to mind.
To check for an exit program:
==> wrkreginf
Then scroll down to the QIBM_QTG_DEVINIT exit point. Enter option 8=Work with exit programs and see if any exit programs are registered. What to do if there are...? Not sure... it depends on whether it's a commercial product or home-grown or shareware or...?
Any commands such as wrkreginf must be executed under sufficient authority of course.
Tom
To see the model, execute:
==> dspsysval qmodel
To see the OS/400 version/release, execute:
==> dspdtaara qss1mri
The VRM will be in the first six displayed characters and will look like V4R5M0 or similar. The model and VRM will give us hints on your potential hardware and any software tools you might have.
You _could_ test whether an IP filter is active just by deactivating any current ones, but we don't know what else might be protected by them. And if we don't know what the names of your filters (if any) are nor where they might be stored, we'd have a tough time reactivating them. Note that _outbound_ packets can also be filtered by the AS/400 integrated firewall.
OTOH, packet filters can provide an additional kind of info if configured for it. Packets that arrive at the interface can also be logged for analysis. If logging is turned on for port 23, it could be a fundamental proof that telnet packets are arriving and tell what the IP source address is.
Because you can in fact telnet to your AS/400, we know the telnet server is running. (And I assume it's running on port 23.) Because you can also telnet from outside to another system on the same subnet, we can "assume" that the basic routing is okay through your ISP and router. It's _possible_ that the port forwarding was in error when pointed to the AS/400, but I imagine that was looked at closely; so we'll "assume" it was okay.
So, our assumptions say that telnet packets are arriving but the telnet server is not getting a response back out. Either the response packets are not surviving the trip or the telnet server is somehow being blocked.
If response packets are making it back out from other systems on the same subnet, we'll "assume" the telnet server is being blocked. I see two likely possibilities. First and less likely is the integrated firewall. Second and more likely, there's a telnet exit program that's rejecting the connection from an outside address. I'm sure there are more possibilities; they just don't come to mind.
To check for an exit program:
==> wrkreginf
Then scroll down to the QIBM_QTG_DEVINIT exit point. Enter option 8=Work with exit programs and see if any exit programs are registered. What to do if there are...? Not sure... it depends on whether it's a commercial product or home-grown or shareware or...?
Any commands such as wrkreginf must be executed under sufficient authority of course.
Tom
Hi Guys
looking back through some other stuff - is it anything to so with authority ie do you need to use.
addsvraute
ps
this is a wild guess.
looking back through some other stuff - is it anything to so with authority ie do you need to use.
addsvraute
ps
this is a wild guess.
Active 1 day ago
Dave:
Boy, I hope server authentication entries don't have anything to do with this; life would get complicated in a hurry.
My understanding is that server authentication entries are primarily used when a process on the AS/400 needs to authenticate to some remote server. A common use is for DDM over TCP/IP. Since the OS/400 DDM _client_ has no way to send profile/password combinations for authentication over TCP/IP to a remote server, IBM decided to use server authentication entries plus perhaps some parallel communications to get DDM authentication working for the client. ("parallel" would mean some secondary thread using the same socket rather than a separate process; but it's a pure guess)
That is, an entry might be used if the telnet function were outbound, but I don't see it inbound.
Besides, it's hard to see any connection to authorities since telnet does work just fine -- as long as it originates on the local sub-net. An authority issue would be unlikely to show up based on remote address. (AFAIK)
Tom
Boy, I hope server authentication entries don't have anything to do with this; life would get complicated in a hurry.
My understanding is that server authentication entries are primarily used when a process on the AS/400 needs to authenticate to some remote server. A common use is for DDM over TCP/IP. Since the OS/400 DDM _client_ has no way to send profile/password combinations for authentication over TCP/IP to a remote server, IBM decided to use server authentication entries plus perhaps some parallel communications to get DDM authentication working for the client. ("parallel" would mean some secondary thread using the same socket rather than a separate process; but it's a pure guess)
That is, an entry might be used if the telnet function were outbound, but I don't see it inbound.
Besides, it's hard to see any connection to authorities since telnet does work just fine -- as long as it originates on the local sub-net. An authority issue would be unlikely to show up based on remote address. (AFAIK)
Tom
Active 1 day ago
Dave:
Agreed... I was half-expecting that you'd have additional comments after mine that would make me re-think things; wouldn't be the first time. And I figured I'd put my understanding into the thread just in case anyone else had better detail to add -- I'm perfectly happy being corrected and this is as good a place as any for it.
Tom
Agreed... I was half-expecting that you'd have additional comments after mine that would make me re-think things; wouldn't be the first time. And I figured I'd put my understanding into the thread just in case anyone else had better detail to add -- I'm perfectly happy being corrected and this is as good a place as any for it.
Tom
Here's what I've found so far:
The command:
==> dspsysval qmodel
Gave results:
System value . . . . . : QMODEL
Description . . . . . : System model number
Model number . . . . . : 170
Then the command:
==> dspdtaara qss1mri
Gave me a large table, within it was:
V4R5M000
The command:
==> wrkreginf (and then navigate to the QIBM_QTG_DEVINIT exit point) showed me there were no Exit Programs.
Now I have to admit here I'm not much of an AS/400 admin, so Tom I'm going to need a little more detail in getting to the firewall config. Your directions "Use OpsNav, navigate to your AS/400->Network->IP Policies->Packet Rules to begin exploring" seems like simple directions, but I'm not sure how to get into the Network IP Policies menu, and what is this "OpsNav"? All I have is the telnet login that puts me at the standard terminal menu with a command prompt. The shell commands you have given me before seem to be working though, as seen above, I just don't know what shell command to use to get into the Network config. Suggestions?
Thanks EVERYONE for the help, I feel we're right on the edge of figuring this out.
The command:
==> dspsysval qmodel
Gave results:
System value . . . . . : QMODEL
Description . . . . . : System model number
Model number . . . . . : 170
Then the command:
==> dspdtaara qss1mri
Gave me a large table, within it was:
V4R5M000
The command:
==> wrkreginf (and then navigate to the QIBM_QTG_DEVINIT exit point) showed me there were no Exit Programs.
Now I have to admit here I'm not much of an AS/400 admin, so Tom I'm going to need a little more detail in getting to the firewall config. Your directions "Use OpsNav, navigate to your AS/400->Network->IP Policies->Packet Rules to begin exploring" seems like simple directions, but I'm not sure how to get into the Network IP Policies menu, and what is this "OpsNav"? All I have is the telnet login that puts me at the standard terminal menu with a command prompt. The shell commands you have given me before seem to be working though, as seen above, I just don't know what shell command to use to get into the Network config. Suggestions?
Thanks EVERYONE for the help, I feel we're right on the edge of figuring this out.
don't you have to add your usrprf to an authorization list
in client access in order to get it from the outside?
in client access in order to get it from the outside?
Active 1 day ago
wileya:
Since connection is possible from the same subnet, authorities _ought_ to be already correct. Also, the error is "Connect failed" meaning it's more closely related to communications rather than authorities (probably). However, the error is _not_ "Connect rejected" or "Unable to connect", which would more likely indicate either that the server wasn't active or that the port itself was blocked perhaps by a router/external firewall, i.e., the packets were not received and acknowledged by the server. I can't recall circumstances resulting in the text "Connect failed", but that could just be memory failure of mine.
treellc:
Okay, then it's likely an AS/400e system and 'reasonably' current.
OpsNav = Operations Navigator, or nowadays I think it might be iSeries Navigator. This is the GUI administration client that allows access to more advanced functions than are easily available through a pure terminal session. Numerous functions can only be done on green-screen by API calls. OpsNav has builtin functions that call the APIs according to the options you click.
The big example for you would be access to the IP Security firewall and logging functions. By turning on packet logging (packet journaling), you could review journal entries to know what packets are actually arriving at port 23 on the AS/400. I've never looked into what's required to configure and enable logging through the green-screen though it's certainly possible.
But it does need to be installed on a PC if it isn't already on a local PC, and then, of course, it needs to be configured to know where the AS/400 is on your network.
Further, in order to be installed on the PC, either the install CD needs to be found or it has to have been previously loaded to the AS/400 (or other local server). Nothing unusual there.
OpsNav is a component packaged into Client Access. If on the AS/400, you should be able to find it in a Windows Network Neighborhood share under the AS/400 in a share named QCA400. This share is broadcast by default if the Windows network component on the AS/400 is started. To start it, use:
==> strtcpsvr *netsvr
And of course, in order for that to succeed, the NetServer function must be configured for your Windows domain. And of course, in order to configure it easily, you'd use OpsNav.
Which means you'd start from the CD shipped with the system for Client Access.
Which means you hope for the CD or for a previously correct NetServer configuration.
There was a set of NetServer green-screen tools that could be downloaded from IBM. They were put together mostly to provide demo code for the NetServer APIs but worked well enough to let you get some basics going. I'll see if I can track it down in case you can't get OpsNav installed any other way.
Tom
Since connection is possible from the same subnet, authorities _ought_ to be already correct. Also, the error is "Connect failed" meaning it's more closely related to communications rather than authorities (probably). However, the error is _not_ "Connect rejected" or "Unable to connect", which would more likely indicate either that the server wasn't active or that the port itself was blocked perhaps by a router/external firewall, i.e., the packets were not received and acknowledged by the server. I can't recall circumstances resulting in the text "Connect failed", but that could just be memory failure of mine.
treellc:
Okay, then it's likely an AS/400e system and 'reasonably' current.
OpsNav = Operations Navigator, or nowadays I think it might be iSeries Navigator. This is the GUI administration client that allows access to more advanced functions than are easily available through a pure terminal session. Numerous functions can only be done on green-screen by API calls. OpsNav has builtin functions that call the APIs according to the options you click.
The big example for you would be access to the IP Security firewall and logging functions. By turning on packet logging (packet journaling), you could review journal entries to know what packets are actually arriving at port 23 on the AS/400. I've never looked into what's required to configure and enable logging through the green-screen though it's certainly possible.
But it does need to be installed on a PC if it isn't already on a local PC, and then, of course, it needs to be configured to know where the AS/400 is on your network.
Further, in order to be installed on the PC, either the install CD needs to be found or it has to have been previously loaded to the AS/400 (or other local server). Nothing unusual there.
OpsNav is a component packaged into Client Access. If on the AS/400, you should be able to find it in a Windows Network Neighborhood share under the AS/400 in a share named QCA400. This share is broadcast by default if the Windows network component on the AS/400 is started. To start it, use:
==> strtcpsvr *netsvr
And of course, in order for that to succeed, the NetServer function must be configured for your Windows domain. And of course, in order to configure it easily, you'd use OpsNav.
Which means you'd start from the CD shipped with the system for Client Access.
Which means you hope for the CD or for a previously correct NetServer configuration.
There was a set of NetServer green-screen tools that could be downloaded from IBM. They were put together mostly to provide demo code for the NetServer APIs but worked well enough to let you get some basics going. I'll see if I can track it down in case you can't get OpsNav installed any other way.
Tom
Active 1 day ago
...also, don't know I didn't ask right off the bat, what does tracert from the external PV show?
Tom
Tom
Active 1 day ago
...also, what TN5250 product are you using? If it's Client Access, you can try CWBPING hostname.or.ipaddress from a PC command line. It should give some info on possible ports or services that aren't available.
Tom
Tom
www.connectrf.com/Documents/TelnetSessionTroubleshooting.pdf
check this out, you might get real interested around page 7
check this out, you might get real interested around page 7
Featured Post
This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Read on to get a few ideas on how to promote your next corporate event.
A new hacking trick has emerged leveraging your own helpdesk or support ticketing tools as an easy way to distribute malware.
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses
Course of the Month4 days, 15 hours left to enroll
670 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.