RE: ACS 5250 VPN Issues

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