PFM User Telnet (port 23) Disconnection Issue – Summary of Investigation and Actions

Is there any document to configure a VPN tunnel between client VDI and then connecting to PFM in Azure
DB Server.

• If feasible, this may allow configuration of Telnet keep-alive or session delay parameters, which could help reduce intermittent disconnects.

Summary of Investigation and Actions

Issue Overview:
Since the migration of PFM from AIX (ATOS) to Azure Windows in March 2025, users intermittently experience “Communication Terminate” errors during Telnet sessions to the InterSystems Caché database. The issue occurs randomly—sometimes once in two weeks, sometimes several times per day—and affects only Telnet-based sessions (not the web interface).

• Sporadic disconnects from telnet sessions initiated by client to PFM application in Azure.
• Most reports appear to come between 8am to 11am local time.
• Client reports are coming from users on their 10.119.x.x subnet which are for their remote users accessing their VDI type environment then connecting to PFM in Azure.
• Disconnects occur while user is actively working.  It is very sporadic, not always the same users.  Disconnect can occur at different times, days, months, etc.  Basically, no pattern detected.

Troubleshooting Timeline & Key Actions

1. Initial Investigation (April–June 2025)

• Confirmed no network-wide or database service outages.
• Continuous ping logs captured minor latency spikes (up to 2000ms), possibly triggering Telnet drops.
• Verified no firewall or IDPS blocks for user IPs.
• Disabled NetBIOS on both TEST and PROD servers—no improvement.

2. SSH Migration Attempt (June–July 2025)

• SSH (Port 22) was enabled and tested but failed due to application limitation.
• InterSystems confirmed that Caché supports only Telnet for direct logins—SSH requires OS login, not compatible with PFM user model.

3. InterSystems Inputs (July–August 2025)

• Identified Windows network errors 64 (“Network name unavailable”) and 121 (“Semaphore timeout”) occurring during Telnet disconnects.
• Confirmed ctelnetd.exe (Telnet daemon) remains active with the same PID—indicating intermittent network interruptions rather than service crashes.
• Recommended antivirus/EDR exclusion for ctelnetd.exe and Cache directories to avoid interference.
• Suggested collecting 24h ^pButtons logs for performance monitoring.
• Later found one instance of ctelnetd.exe crash (faulting module cctrl.dll).

4. Network & Security Team Findings

• No packet drops or IDPS blocks found for reported user IPs.
• One false-positive CVE signature (“Zyxel Command Injection Attempt”) was adjusted .
• Security team confirmed CrowdStrike detected no active blocking.
• AV/EDR exclusion request denied for policy reasons, but scans were reviewed for correlation (none found).

5. Microsoft Involvement (August–September 2025)
Two cases opened with Microsoft:

• (2509170040013067 – Network Team)
  • Azure Firewall (AFW) and ExpressRoute reviewed—no session drops, no performance anomalies.
  • Data throughput (20–70 Mbps) and metrics within normal limits.
• (2509190030007982 – Windows Team)
  • Deep packet analysis of 463,950 packets showed no TCP resets, retransmissions, or loss.
  • Telnet sessions and TCP/IP stack behavior deemed healthy.
  • No OS-level or NIC-related cause identified.