|
I’ve traced the problem down to the Large_Send Offload. This parameter must match in the switch, VIOS and OS. It is ON by default in IBM I and can not be permanently turned off. You can turn it off for testing (which I did to confirm this is the problem) but the change is only affective until the next IPL.
Customer is trying to find how to change this on their Cisco switch now.
From: DrFranken<mailto:midrange@xxxxxxxxxxxx>
Sent: Friday, May 29, 2020 2:06 PM
To: Midrange Systems Technical Discussion<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: ACS 5250 VPN Issues
It was kinda smelling like one of those deep packet inspection thing in
the firewall. Looking at commands and passing ones it knows and blocking
others. However since you gained access to a second machine and they
work there you are likely correct that it's not the firewall.
I have a hard time thinking it's network either because any of the
commands could result in more data than a single packet.
From the way you state it the commands either work or don't work and
are repeatable and consistent?
That really makes me think exit points.
Gotta say this is a weird one!
- Larry "DrFranken" Bolhuis
On 5/29/2020 1:41 PM, Steve Pavlichek wrote:
IBM is thinking it is a network config issue between the IBM I, VIOS and switch port.
I had customer give me access to another IBM I system and there was no problem, so the issue in not VPN related.
From: Patrik Schindler<mailto:poc@xxxxxxxxxx>
Sent: Friday, May 29, 2020 1:29 PM
To: Midrange Systems Technical Discussion<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: ACS 5250 VPN Issues
Hello Steve,
Am 29.05.2020 um 18:20 schrieb Steve Pavlichek <spavlichek@xxxxxxxxxxx>:
To make this even more interesting, some commands work and some don’t. NETSTAT *IFC works, WRKACTJOB does not. GO LICPGM works but WRKLICINF does not.
Same results using ACS and putty.
I’m running as QSECOFR, so it should not be an authority issue.
This sounds like a MTU issue. "Big" packets with lots of data in them getting lost in transfer, because some link in between cannot cope with the "usual" maximal size of 1500 Bytes.
If for any reason, the VPN software prohibits fragmentation, routers left and right of the smaller-mtu-link will send an ICMP answer. When there's a misconfigured firewall in between blocking ICMP "for more security", you'll get the behaviour you observe.
How to test this (with Linux):
ping -s 1400 -M do ibmi-IP
Increase 1400 Bytes until there's no more answer from the IBM i box. The last functioning packet size is the biggest one working over the link in question.
:wq! PoC
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.