Azure VPN Client P2S file uses backslashes, which is incorrect

Question

The "VPN client" zip files from Azure Portal use backslashes in paths and expand to bad files on macOS.

As of 2023-08, it looks like the "VPN client" zip files produced by Azure VPN gateway point-to-site configurations use backslashes in the file path names inside the ZIP entries, which cause them to expand to the "wrong" files on macOS and produce warnings on Linux.

In the Azure Portal blade for a Virtual Network Gateway, if I have it configured for a point-to-site VPN, and select "Point-to-site configuration" in the navigation bar and then click the "Download VPN client" button [1], that downloads a zip file, named "VPN-Gateway.zip" or whatever "<gateway>.zip" I have.

When I unzip that zip file on Windows by double-clicking it or right-clicking and doing "Expand all", it produces a directory with some subdirectories as described on this page. However, on macOS, if I click that zip file, it expands to several files with backslashes in their names in a single-level folder. [2] And when expanding on Linux using its unzip utility, it gives me a warning about "backslashes in path names" but then produces subdirectories.

I think this is because the zip file is incorrectly using backslashes instead of slashes in the path names inside the Zip entries in that file. The default Windows unzipper utility handles that by creating subdirectories, but the default macOS unzipper treats backslashes as regular characters and does not produce subdirectories.

I think it would be good if this "VPN client" zip file expanded to the same folder structure on all supported client OSes, including macOS. This would happen if the zip file were produced using forward slashes instead of backslashes as the file/path separator in its zip entries. I think Microsoft should consider altering the code that produces this zip file to do so.

My basis for thinking that forward slashes are corret and backslashes are wrong here is:

• The ZIP file format specification, which says "All slashes MUST be forward slashes '/' as opposed to backwards slashes '' for compatibility with Amiga an UNIX file systems etc." in section 4.4.17.
• This .NET "Mitigation: ZipArchiveEntry.FullName Path Separator" page in the .NET Framework documentation, which notes that .NET Framework 4.6.1 has changed to using forward slashes in ZIP entry paths, and says that this brings .NET in to conformity with the above zip file format specification.
• This PowerShell.Archive "All path separators needs to be normalized to forward slash" bug ticket and the associated change in Microsoft.PowerShell.Archive 1.2.3.0, which changed PowerShell to use forward slashes in the ZIP files it produces.
• The first few pages of Google results for "zip file backslash".

My basis for thinking that macOS is a supported client OS for Azure VPN P2S stuff here, and thus that Microsoft should consider making this "VPN Client" zip file work good on macOS, is:

• This "VPN Gateway FAQ" page in the Azure docs, which says that "macOS version 10.11 or above" is one of the supported client OSes for Azure VPN Gateways, and "Azure supports Windows, Mac, and Linux for P2S VPN".

Any chance I could get an Azure Portal or VPN Gateway developer interested in this issue, and get them interested in fixing up the ZIP file to use forward slashes instead of backslashes in the zip entry paths so it works good on macOS?

This is a minor issue: the contents of the extracted files are correct, and setting up a VPN client connection using them works fine, as long as you can read the instructions and translate stuff like "in the 'Generic/' folder" to "the file that starts with 'Generic'". However, I'm a sysadmin who needs to get non-technical users to be able to set up VPN connections on their client machines using this file, and any deviation from the exact documentation or expected file names/directory structure makes that more difficult. My current workaround is to download that VPN client zip file on Windows, unzip it, and then re-zip it using a utility that produces a zip file with correct forward slashes. But that's a bit of a bummer; we can do better here, right?

[1]

[2]