Proxy and web filter configuration

If your organisation routes traffic through a proxy, secure web gateway or SSL-inspecting firewall, file-type controls and destination policies can silently block the files Robopack needs to move. The usual symptoms are uploads that never complete, package downloads that fail, or SSL/certificate errors when connecting.

This page lists what to allow. It is written for the administrator of your proxy or web filter.

Recommended approach

Rather than enumerating file types, the cleanest fix is a rule scoped to Robopack's destinations that allows all file types, for both upload and download. Robopack's traffic is limited to a small set of known hosts, so a destination-scoped allow rule is both simpler to maintain and less likely to break when Robopack handles a new file type.

If your filter requires an explicit list of file types, use the tables below.

Destinations

Both conditions must hold. A file-type rule never applies if the destination itself is blocked, and an allowed destination still fails if the file type is blocked.

Destination	Used for
app.robopack.com	The Robopack portal, API and uploads
*.blob.core.windows.net	Robopack's Azure storage, which holds package content for upload and download

Add these to your allowed URL category, and exclude them from SSL inspection if you see certificate errors (see SSL / certificate errors).

Allow "unknown" / "other" file types for these destinations

Most filters classify .intunewin — the packaged output you download from Robopack — and some vendor payloads as an unknown or other file type rather than any named category. That category must be allowed for the Robopack destinations, or downloads keep failing after everything obvious has been whitelisted. This is the single most common cause of residual problems.

File types

Grouped the way most web filters categorise them. Allow each for both upload and download against the destinations above.

Installers and executables

Extension	Why Robopack moves it
exe, scr	Application installers
msi, msp, mst	Windows Installer packages, patches and transforms — .mst transforms are very common in custom packages
msix, msixbundle, appx, appxbundle	Modern app packages
cab	Cabinet archives inside installers
dll	PSADT v4 ships DLLs inside the package; some installers carry side-by-side DLLs
intunewin	The packaged output downloaded from Robopack — see the note above about the unknown category

Scripts and PSADT files

Extension	Why Robopack moves it
ps1, cmd, bat	Install, uninstall and custom scripts
psm1, psd1	The PSADT v4 module and its config.psd1 / strings.psd1
xml	PSADT v3 AppDeployToolkitConfig.xml, detection and configuration files
json	Configuration files and manifests
vbs, js, wsf, reg	Legacy scripts and registry files inside packages
ini, cfg, inf	Driver and configuration payloads inside packages

Archives

Extension	Why Robopack moves it
zip, 7z	Package uploads and downloads. Allow the plain category and any "archive containing scripts" category your filter has — custom packages legitimately contain ps1, cmd and vbs files inside zips
rar, tar, gz	Occasionally used for vendor payloads

Data and documents

Extension	Why Robopack moves it
csv	Radar scan imports and bulk imports
xlsx, txt, log, pdf, html	Exports, logs and reports

Images

Extension	Why Robopack moves it
png, jpg, ico, bmp, svg	Application icons and PSADT banner/logo uploads

Certificates

Extension	Why Robopack moves it
pfx, cer, p12	Only if you use package signing with your own certificate

Checklist

1. Add app.robopack.com and *.blob.core.windows.net to the allowed URL category.
2. Create a file-type rule scoped to those destinations that allows all types for upload and download — or, if a list is required, the types above.
3. Allow the unknown / other file-type category for those destinations.
4. If SSL or certificate errors persist, exclude the destinations from SSL inspection.

Related

• Common Issues: SSL / certificate errors
• Custom Packaging — what goes into an uploaded package
• Certificates & Package Signing