Ping Support for Legacy Applications

Some legacy applications and scripts send an ICMP ping to a server and wait for a reply before they open a TCP or UDP connection. For example, a script might ping several file servers and connect to whichever answers fastest. Ping support for Netskope Private Access (NPA) lets these applications work without modification.

When the feature is enabled, the Netskope Client sends the ping request (ICMP echo request) to a private application through the NPA tunnel. The Publisher forwards it to the application server, and the server’s real echo reply comes back to the application. NPA does not generate replies on the server’s behalf. If the server, Publisher or path is down, the ping fails.

Requirements

• Supported OS: Windows. macOS and Linux are not supported.
• Supported traffic: IPv4 ICMP echo request and echo reply with default payload sizes (32 bytes on Windows).

How access is controlled

• The destination must be defined in a private app that the user is steered to. A Real-time Protection policy must also allow the user access to that app.
• Matching uses the destination host only. Ports and protocols in the app definition or policy are ignored for ping. For example, a user allowed to reach fileserver.corp.local on TCP 445 can also ping fileserver.corp.local.
• If no private app matches, or the policy doesn’t allow access, the ping times out. The user does not receive a “destination unreachable” response.
• Destinations that are not private apps, or that are bypassed, are not affected. Their pings use the local network as before.
• You can ping a private app by hostname or by IP address.

Supported scope and limitations

• Only echo request and echo reply are supported. Other ICMP message types are dropped, so traceroute (tracert) does not work through NPA.
• Custom packet sizes are not supported. Pings larger than the path MTU are fragmented, and fragmented pings are dropped, so they time out.
• IPv6 and ICMPv6 are not supported.
• Rate limit: each client allows a burst of 20 pings, then 5 pings per second. Pings above this rate are dropped. Standard ping usage is not affected.
• Policy changes on Windows: a change to a policy, such as Allow to Block, can take about 30 seconds to apply to ping. Windows reuses the same ping session, so the change applies once the existing session has been idle for about 30 seconds.
• Logging: As of today, ping traffic is not recorded in Network Events.
• If the private app has DNS validation enabled and the application is unreachable, name resolution fails (“could not find host”) and no ping is sent.

Ping timings

Ping round-trip times include the full ZTNA path: Client → Netskope data plane → Publisher → application server. They are also affected by the outer TLS-over-TCP tunnel, so a TCP retransmission can produce an occasional high value. When Publisher DNS is disabled, the first ping to a hostname can take longer while the destination is resolved. Path selection can differ between destinations and between connections.

These results exist for application compatibility. Do not use them to measure network latency or packet loss, or to decide which server is nearest.

Troubleshooting and Support

Netskope Support does not accept client-side ping results for NPA private applications as diagnostic evidence. For connectivity issues, provide Publisher logs and Publisher-side diagnostics, including a ping from the Publisher to the application server. Use Collect Logs from a Publisher where it’s enabled, or see Troubleshooting Performance and Connectivity using Ping, Traceroute, or Telnet.