You don't need Bonjour discovery to print over a VPN

You have probably been told that printing from an iPhone over a VPN requires Bonjour discovery to cross the tunnel. That belief sends people toward TAP bridges and multicast relays that fix nothing. AirPrint accepts an explicit destination: a configuration profile can hand the phone a printer's address, resource path and port. Discovery never has to happen for that entry to appear in the print sheet. What the payload does not do is create the route, make a non-AirPrint printer speak IPP, or authorize the job.

The myth starts with a true observation

Bonjour is link-local multicast by design. A routed, point-to-point tunnel does not carry those groups, so a phone on a VPN cannot browse printers on the far LAN and neither can a laptop on the same tunnel. The correct conclusion is not that printing needs a bridge; it is that browsing needs a different delivery mechanism, and an explicit list is that mechanism.

Multicast relays exist and some networks run them well, but they solve a discovery requirement you may not have. If the deployment only has to print to one approved device, publishing that device is smaller, testable and far easier to withdraw than extending a broadcast domain across a tunnel.

What the payload actually carries

The com.apple.airprint payload holds an array of printer dictionaries. Each dictionary takes an IPAddress, which may be a literal address or a hostname, a ResourcePath, an optional Port and an optional ForceTLS. Apple documents Port and ForceTLS from iOS 11 onward, so a mixed fleet needs that stated before rollout.

The path is the field people guess. ResourcePath mirrors the rp value in the printer's _ipps._tcp or _ipp._tcp Bonjour record. It is frequently ipp/print on modern driverless printers and frequently vendor-specific on older ones. Copying a path from a different model produces a queue that appears and then refuses every job.

An item in the array looks like this, with placeholder values that are not a tested endpoint:

<dict>
    <key>ResourcePath</key>
    <string>ipp/print</string>
    <key>IPAddress</key>
    <string>printer-07.office.example</string>
    <key>Port</key>
    <integer>8631</integer>
    <key>ForceTLS</key>
    <true/>
</dict>

That fragment is not a profile. It is one element of the AirPrint array inside a payload, and the payload still needs its own metadata plus signing or MDM delivery. The AirPrint printer dictionary is the reference for the field meanings.

Collect the values from the printer, not from a search result

On a Mac that already prints to the device, ippfind or dns-sd -B _ipp._tcp shows the advertised instance, and the printer's own web interface usually lists the IPP path and port. Record all four values in the deployment note so the next person does not re-derive them from a screenshot.

Then decide about TLS deliberately. With ForceTLS true the phone must trust the certificate the printer presents, and a self-signed certificate fails unless you also deploy the trust anchor. Turning TLS off to make a queue work is a decision about the network path, not a workaround for an inconvenient certificate.

Delivery, then two opposite failures

Deliver the payload through your device management channel where one exists, and treat a manually installed profile on a work phone as the exception it is. Once installed, the printer should appear in the print sheet with no discovery traffic at all. That appearance is the only thing the payload was ever meant to guarantee.

A printer that appears but fails every job has a route, port, path or TLS problem, and none of those is settled by the payload.

A printer that never appears has a delivery or payload problem instead: the profile did not install, the array is malformed, or a value does not match the device. Re-read the values and the target device before touching the VPN. Adding a discovery relay to fix a listing problem is an expensive mistake, because the listing never depended on discovery in the first place.

Keep the entry maintainable

Prefer a hostname over a literal address where you control the zone, so an address change does not invalidate every installed profile. That hostname has to resolve from the phone while the tunnel is up, which puts it back in the split-DNS conversation rather than the printing one.

Write the printer owner and the profile owner into the deployment record. When the queue moves, update the published destination on purpose, because an old entry does not expire on its own and keeps directing users at a retired device.

None of this makes a printer AirPrint-capable. The payload publishes a destination, and the device still has to speak IPP.