First, name the box correctly
This is the IBM i operating system on a Power System super computer… well, I think it’s pretty super 😉
The operating system is backwards compatible with old AS/400 and iSeries workloads, which is why the client’s existing code still runs. The badge on the cabinet changed a long time ago. The security model did not get a free pass because the LPAR now lives in someone else’s data centre.
If you are job-hunting in this world, put IBM i and Power System on the CV. AS/400 and iSeries tell a recruiter your vocabulary stopped when the hardware was rebadged.
The fact that the machine itself is on a local network, a remote network or an cloud network is purely a matter of location.
Secure connection is key, so let’s get into the nitty gritty:
What actually travels when you “just open ACS”
Remote IBM i work is rarely one session.
You want a 5250 green screen. Then Navigator. Then ACS data transfer. Then Run SQL Scripts. Then IFS. Then maybe IBM BOB or VS Code or RDi. Then a stored procedure test from a workstation driver. That is a pile of TCP ports, not one tidy HTTPS URL.
Typical services include:
- Telnet or TLS Telnet for 5250 (23 or 992)
- Server mapper (449)
- Signon, remote command and central servers (8476, 8475, 8470)
- DRDA / database (446)
- File server for IFS (8473)
- SSH (22) if you have turned it on like a sensible person
IBM’s own notes for IBM i in IBM Cloud are blunt: port 23 is not opened by default. That is a hint. They do not want raw Telnet hanging on the public internet, and neither should you.
Plain Telnet is still the gift that keeps on giving to packet sniffers. User profile and password can travel in the clear. Encrypt the 5250 session with TLS and you have fixed that path. You have not fixed ODBC, IFS, data transfer, or the next tool somebody installs next Tuesday.
What a VPN actually does for IBM i
A VPN builds an encrypted tunnel from your device (or your office firewall) to the cloud network that holds the partition. After that, ACS, SSH, JDBC and the rest talk to private addresses, as if the Power System was still on the other side of your own switch.
IBM documents this properly for Power Virtual Server: site-to-site VPN for the office, client-to-site VPN for laptops, usually via VPC, then a path into the Power workspace. You are not inventing a weird IBM i-only trick. You are using the same private connectivity the cloud expects.
Three practical wins:
1. One lock instead of twelve holes
TLS on Telnet protects Telnet. A VPN can protect every IP conversation you allow down that tunnel. That matters on IBM i because the workstation tools are chatty. Open 992 to the world and you still have to explain the 847x ports. Put the partition on a private subnet and only the VPN (or Direct Link) can see it.
2. The partition stops being a public pet
A public IP on an IBM i LPAR is an invitation. Bots do not care that your menu is called MAIN. They care that port 23, 992 or 446 answered. Keep the system off the public internet. Reach it through the tunnel. Sleep better.
3. Hybrid shops stay honest
Most cloud IBM i work is not “cloud only”. Users still need the on-prem file share, the office printer queue, or the old test box in the plant. Site-to-site VPN (or VPN plus Transit Gateway in IBM Cloud) lets the same user reach both sides without turning every service into a public website.
VPN is not a substitute for IBM i security
Programmer humour moment: a cheap VPN with QSECOFR and password PASSWORD is just a very expensive way to encrypt your own disaster.
Still do the boring IBM i work:
- No default passwords. Ever.
- Network attributes and *PUBLIC authorities that match least privilege
- TLS for 5250 and HTTP even inside the VPN when you can
- SSH instead of FTP
- Exit programs and audit journals switched on
- MFA on the VPN and on privileged IBM i profiles
IBM said this years ago and it still holds: SSL protects an application that knows SSL. VPN can wrap the traffic between two networks. Use both when you can. Do not pick one and declare victory.
Also put MFA on the VPN login. A stolen laptop plus a remembered PSK is how “we had a VPN” becomes an incident report.
The latest IBM i release (7.6 at the time of writing) finally puts multi-factor authentication inside the operating system, which is the sort of security feature auditors have been asking for and operators have been bolting on with third-party tools for years. Instead of a password alone, a user can be required to prove who they are with a TOTP code from a normal authenticator app (the same kind of six-digit number you already use for a bank), and that check can sit on 5250 sign-on, Navigator, host services and even SST or DST. It is not a magic cloak: you still need a sensible security level, a modern password level, time sync, and a plan for batch jobs that used to swap profiles without anyone typing anything. What it does mean for a cloud move is simple. The platform you land on can demand more than “user and password on a laptop in a cafe,” which is exactly why a VPN plus IBM i 7.6 MFA is a stronger story than either one on its own.
Client VPN versus site-to-site
For a developer on a sofa with ACS and VS Code, client-to-site VPN is the usual answer. Connect the client, then point ACS at the private IP of the IBM i partition.
For the company office that needs every user and every batch job to see the cloud LPAR all day, site-to-site is cleaner. The tunnel lives on the firewall. Nobody has to remember to click Connect before WRKACTJOB.
PowerVS often needs that extra hop: VPN lands in VPC, then you route into the Power workspace. Read the current IBM diagram for your workspace type (PER versus non-PER) before you guess. Guessing at CIDR overlaps is a great way to spend a Friday night.
If the workload is large and permanent, look at Direct Link as well. VPN over the internet is the affordable, flexible option. It is not the lowest-latency option.
A sane remote-access pattern
- IBM i LPAR on a private network only.
- VPN (client or site) into the cloud network.
- ACS and SSH aimed at the private address.
- TLS Telnet still enabled, so the session is encrypted even on the private side.
- Jump host or bastion if the cloud design requires it. Some PowerVS layouts do.
- MFA on the VPN. Tight security groups. Logging that somebody actually reads.
That is not exotic. That is how you stop a hotel Wi-Fi from becoming your signon server.
Final thoughts
Moving IBM i to the cloud does not make Telnet safer. It makes the blast radius bigger when you get it wrong. A VPN will not modernise your DDS files or fix a *ALLOBJ profile you created in 1998. It will stop the public internet from knocking on every IBM i host server port you forgot about.
Use the VPN. Keep the partition private. Encrypt the sessions anyway. Call the platform IBM i on Power, because that is what you are securing.
If you have a favourite PowerVS or ACS-over-VPN war story, drop it on the blog or the YouTube channel. I read them.
Until next time, keep those IBM i systems humming. And keep port 23 off the internet.
