Link to home
Start Free TrialLog in
Avatar of ruralsolutions
ruralsolutionsFlag for United States of America

asked on

SonicWall NSA 250 drops connections to AS400 IBM iSeries

I have recently installed a SonicWall NSA 250 in a county office. They all use the AS400 system, the IBM iSeries. Ever since the firewall was installed, the users have been complaining about the AS400 terminal sessions going unresponsive. Before the SonicWall this never happened, but now, according to the users, at random intervals, the AS400 screen will go completely black, and they need to close it completely, reopen their sessions and log in again. As best as I can figure, this does not happen during active use, the users have been idle for as little as one minute or as long as several hours.

I have opened tickets with SonicWall, worked for days, but they say it is not the firewall, it must be something on the iSeries. I called iSeries support, they indicated one nearby county had the same problem and fixed it... But no one could remember the fix and the documentation was gone.

I have allowed all LAN to WAN traffic and services going to the remote iSeries server IP address as well as allowed all WAN to LAN traffic and services coming from the remote iSeries server IP address. We did days worth of packet capturing, we are allowing fragmented packets.

We are at a loss here, and the users are becoming hostile. Does anyone have any experience with this? Our next step is going to be removing the firewall and running without one for a day to see if the problem persists.

Avatar of John
Flag of Canada image

I would try without the firewall temporarily to see if it improves. I cannot speak from any recent experience about the AS/400. But you do want to check the firewall.

It might be worthwhile to change the MTU on the Sonicwall to 1492 or a bit lower. Default is 1500 and slightly lower MTU works better with DSL. Try this as well.

.... Thinkpads_User
Avatar of ruralsolutions


We have already made the MTU change, it had no effect. It is currently at 1492.

1. Without the firewall
2. Firmware upgrade for the Sonicwall
3. See if you can borrow an alternate router to try
4. If wireless workstations, set Power management to maximum performance
... Thinkpads_User
Avatar of Gary Patterson, CISSP
So everything worked fine, then you installed the Sonicwall, and the problem immediately started - but somehow it is not a Sonicwall problem but an iSeries issue?


I'm an iSeries and Cisco consultant, and I work with Sonicwall regularly, though that's not my specialty.  I've seen this same basic problem (and fixed it) over and over, and with a variety of different firewalls.  

Root cause and fixes vary, but at the heart of it , the problem is usually due to firewall behavior.  Not quite always, but close to it.

Most commonly, the firewall decides the connection is idle or abandoned, and is intentionally breaking the connection.  

But I've seen a long list of problems causing similar behavior (in no particular order):

1) Routing problem or router misconfiguration
2) DNS issue
3) MAC/IP address duplication in the source, destination, or an intermediate network
4) Missing iSeries PTFs or IBM i Access service packs
5) Improper iSeries communications config
6) Improper firewall setup
7) Firewall design incompatible with long periods of inactivity
8) Local or remote ISP configuration or security issue
9) Excessive data drops
10) Windows firewall misconfiguration

IBM has a troubleshooter for Telnet drops:

Sometimes the best fix is on the firewall, sometimes the client system or application, and sometimes the host application or system.

When you establish an outbound TCP connection from your firewall (green screen sessions are TN5250 protocol- TCP - host port 23 - just a flavor of telnet), the firewall creates temporary rules to allow responses back in, if needed.  It also sets up a temporary NAT association if needed.

Most firewalls are smart enough to watch TCP flags and determine when a TCP connection is set up and torn down, and they set up and tear down the NAT and temporary firewall rules as appropriate.  But since not all connections are torn down properly, firewalls usually also have timeouts to dispose of unused connections.

Host applications (or communication stack code) also have mechanisms for detecting dead connections, in order to free up resources when a remote application stops communicating.  

Green-screen sessions run a flavor of the telnet protocol called TN5250.  TN5250 uses TCP as a transport, and the host port is 23.  

Since you've already done a lot of detailed troubleshooting, it is hard to tell you where to start.  

Usually you can look at simultaneous packet captures taken on the AS/400, the client system, and the firewall and pretty quickly zero in on the problem.  Post them if you have them, after sanitizing them of any confidential information, of course. I'd be happy to take a look.

- Gary Patterson

Check out my EE profile:
Thanks for the assistance. I am attaching the transcripts of my sessions with Sonic Wall Support, to let you all see what we have done so far, and maybe offer some insight into the packet capturing diagnosis Sonic did. I am also attaching a file with the dropped packets that Sonic looked over. I will see what I can do about getting another more recent packet capture to look at, but getting one from the AS400 will be difficult, as we do not manage it and their administrator is generally less than helpful...

OK, I'm a little confused.  In your original problem above, you indicated that this is a problem with terminal sessions going unresponsive.

"Terminal session" in an iSeries context usually means TN5250.

I reviewed the transcripts and packet captures you posted, and I don't see any thing in there about terminal sessions.  I see something about an RDP problem, and something about a DOS program, but no mention of terminal sessions.

What terminal software is being used here (please be specific, including version)?

Also, you provided a list of a few dropped packets, but dropped packets alone aren't enough to diagnose the cause of connection drops.  Really need to see the complete flows back and forth, and need to see terminal session traffic. None of the packets you provided look like TN5250 traffic to me.

This kind of problem doesn't really suit itself well to solving in a web forum environment - I'm not sure how I can help without doing some live troubleshooting.

Still happy to help, but need a lot more than this to work with.

- Gary Patterson
Ok, sorry about the lingo issues. I am not an AS400 user, but rather network administration, and since the firewall has been named as the problem, I am the one trying to fix it. I have been using "DOS" and "terminal" as describing the problem to Sonic support. The users here are using a black screen program that everyone just calls the AS400. In talking to local AS400 support, I have learned more about the program, but am still very much not a user.

That being said, today we had a bit of a breakthrough. Our state repaired a 10G line to our county last night that was problematic, and we also changed all of our switches from Auto 1G to 100Fdx as someone recommended to us. Today, not a single drop. Tomorrow we will be changing the network back to Auto 1G to see if that brings the issue back. If it does not, we can look at the issue was state fiber all along.... We are still dropping a lot of packets, but are now thinking it ma not have been our issue in the first place.

No problem- just wanted to make sure we were both working on the same problem :-)

Packet loss (which you hadn't mentioned earlier) can certainly cause Telnet/TN5250 drops,so if you've got that going on, resolve it before looking for come complex causes.

On to the switching issue: I've seen cases where some older devices just don't auto-negotiate properly, but most modern devices do. The problem is easy to spot - you'll see messages logged in the switches or router ports of speed flipping back and forth.

That is often a sign of a physical layer problem: bad cable, bad port, or noise due to EMI.  Swap to a known good cable, swap ports if possible, and reroute cables on the problem path away from power cables, motors, fluorescent lights, etc.

- Gary Patterson
OK, I have an update. Since my last update, I have changed all of our network back from 100 FDx to Auto Negotiate. It made no difference, we are no longer seeing disconnects to the AS400, but we were still bleeding packets. On Friday we had a tech come down from the State to do some maintenance on our router, something they had been pushing off since before Christmas. He removed the router, cleaned it out, and we put everything back in place. After running some tests, we are no longer losing packets or pings from the state systems. So between the connection to the next county, and cleaning up the router on our end, it seems the issues with packet loss and AS400 disconnects are no longer issues. The offices were closed on Friday, so we will see how all the users do today, but so far we have gotten no calls. I will wait a day or so and see if anything changes before closing this question.

It seems this entire process was a wild goose chase to begin with, and a long one at that. The problem never was on our end.

Avatar of Gary Patterson, CISSP
Gary Patterson, CISSP
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial