User printing onsite — multi-subnet restricted network

This page covers how PaperCut Hive and Pocket provide serverless cloud print management in complex multiple-subnet network environments when there are restrictions on communications between subnets. It also outlines the end-to-end technical workflows for job submission and release in two primary network architecture scenarios:

• when communications are blocked between user subnets, but user computers are allowed direct access to printers
• when communications are blocked between the user and printer subnets.

Examples of multi-subnet restricted networks

Computer security is an ongoing concern, and companies need to protect their intellectual property.

Many businesses set up their environments with multiple subnets and data communication restrictions to limit who can access sensitive data on the server infrastructure. These businesses often restrict access to their printer subnets to limit who can access printers over the network, forcing users to submit print jobs via a protected print server and preventing sensitive documents from being intercepted on the network as they are routed from the print server to the printer.

These restricted environments can operate at a single site or across multiple sites connected on a restricted WAN. Network boundaries control access and dictate allowed communication ports.

Typical customers with this setup include:

• small legal firms
• schools
• libraries
• universities
• government agencies
• healthcare providers.

Regardless of the industry, these organizations need to control the flow of access and information within their networks.

Recommended solutions for printing in multi-subnet restricted networks

In complex environments, you can configure your network to restrict communications while still allowing printing. The following scenarios explain how to configure PaperCut Hive or Pocket based on the severity of the communication restrictions.

Method 1: Printing when there are restrictions between user subnets, but access is allowed to the printer subnet

In this scenario, any computer in the network can deliver print jobs directly to the printers; that is, no printer port restrictions exist. However, for security purposes, limited or no communication is allowed between specific different user subnets, such as a guest network and staff network, or a teacher network and student network.

When restrictions exist between user subnets, PaperCut Hive and Pocket use the most appropriate nearby edge nodes (Windows or macOS computers running the PaperCut Hive or Pocket client) within the user’s subnet.

For example, if a teacher submits a print job, the system uses edge nodes in the teacher’s subnet to replicate or retrieve the job. The system would not use edge nodes in the student subnet because the subnet or VLAN boundary prevents communication between the teacher and student subnets. However, any edge node in the originating (teacher’s) subnet can accept and release the print job to any printer, because every user subnet can communicate freely with the printer subnet on the allowed printing ports.

Method 2: Printing when there are restrictions between user and printer subnets

In this scenario, communication between user subnets and printer subnets is restricted, or direct communication between user machines and printers is prevented.

Schools and universities frequently use this setup so that students can access data only on the student subnet and submit print jobs via a print server. This prevents students from bypassing the print server to avoid print charges.

To use PaperCut Hive or Pocket in this scenario, you require either:

• at least one edge node that can communicate with the printers and route print jobs to them
• printers that support Pull Delivery, which retrieve and print stored jobs directly from the Cloud Node.

If your printers support Pull Delivery and integrate with the Full Embedded Printer App, configure Pull Delivery as the primary print delivery method and enable the Cloud Node. In that setup, the printer downloads a copy of a print job from the Cloud Node and prints it directly. This avoids routing jobs via an edge node when they are released. For more information, refer to Pull Delivery in PaperCut Hive.

Consider the following when using Pull Delivery:

• The printer subnets might contain a mixture of printer types, with some not supporting Pull Delivery.
• Some MFD brands require an edge node to communicate directly with the printer for Full Embedded Printer App tasks.
• It’s a good idea to provide backup methods to route print jobs for release.

Because of these considerations, you might need at least one dedicated, always-available edge node to communicate with the printers and deliver jobs.

However, you also need a way to route jobs from the user devices to the dedicated edge node(s). You can route jobs from user devices to dedicated edge node(s) in two ways:

• Create a separate subnet for one or two dedicated edge node computers that all user devices can contact. Use this approach if your organization prevents print traffic from leaving the premises (even if encrypted) or if you need to minimize public internet bandwidth utilization. In these cases, you cannot enable the Cloud Node, so you must selectively allow traffic at the firewall level for the replication and routing of jobs from user subnets to printer subnets.
• Create a separate subnet for one or two dedicated edge node computers and enable the Cloud Node. Enable the Cloud Node to relay print jobs around subnet boundaries, eliminating the need to open firewall ports between user subnets and other subnets. For more information, refer to Managing Edge Mesh nodes.

Create a separate subnet for dedicated edge nodes reachable by user devices

To configure this:

1. Create a new subnet and install one or two dedicated edge node computers.
2. (Optional) If you require iOS printing, promote these edge nodes to Super Nodes and assign them static IP addresses. This provides specific edge nodes for iOS devices to submit print jobs to.
3. Open the required ports to allow all user devices to communicate with the dedicated edge node(s) in the new subnet over the required ports. For a list of required ports, refer to System requirements.
4. Open the standard ports for SNMP, IPP, and RAW printing to allow the new subnet to communicate with the printer subnets over SNMP and standard printing ports.
5. Create a Print Delivery Profile that’s configured with one of the following:
   • Configure the dedicated edge node(s) as Individual selected clients.
   • Configure the new subnet as the network location for Dynamically selected clients.
6. Apply the Print Delivery Profile to all printers.

After setup, when a user submits a print job, it replicates to the dedicated edge nodes or other nearby edge nodes. When the user releases the job, a dedicated edge node in the new subnet will be holding a replicated copy or able to retrieve one from an edge node in the user subnet. The dedicated edge node then delivers the job to the printer.

Create a separate subnet for dedicated edge nodes and enable the Cloud Node

To configure this:

1. Create a new subnet and install one or two dedicated edge node computers.

2. Allow the new subnet to communicate with the printer subnets over SNMP and standard printing ports.

3. Enable the Cloud Node.

4. Create a Print Delivery Profile that’s configured with one of the following:

   • Configure the dedicated edge node(s) as Individual selected clients.
   • Configure the new subnet as the network location for Dynamically selected clients.

5. Apply the Print Delivery Profile to all printers.

6. For supported printers, configure Pull Delivery as the primary print delivery method.

After setup, the system securely replicates a copy of each print job to PaperCut Cloud Services. When a user releases a job, printers that support Pull Delivery download and print the job directly from the Cloud Node. For printers without Pull Delivery support, the dedicated edge nodes in the new subnet download the job from the Cloud Node and route it to the printer.

How printing with PaperCut Hive and Pocket works

For detailed information on print job submission and release in a multiple subnet restricted network environment, refer to Job submission process and Find-Me job release process below.

Pros and cons of PaperCut Hive and Pocket in multi-subnet restricted networks

Network diagrams

Method 1: Printing when there are restrictions between user subnets, but access is allowed to the printer subnet

Method 2 — Option 1: Create a separate subnet for dedicated edge nodes reachable by user devices

Method 2 — Option 2: Create a separate subnet for dedicated edge nodes and enable the Cloud Node

Ports

If you run the Full Embedded Printer App, some MFD platforms need additional ports opened between edge nodes and the MFD to facilitate certain device tasks. For the complete list of ports, refer to System requirements.

Job submission process

The following sections explain the process when a user prints in a multiple subnet environment with restrictions on communications between subnets.

Process for Find-Me printing from Windows, macOS, ChromeOS, and Android

Process for Find-Me printing from iOS

Process for Direct printing from Windows and macOS

Find-Me job release process

When a user releases a Find-Me print job, they can use two methods:

• MFD release
• Mobile device release

After the user releases their job, how you configure PaperCut Hive or Pocket determines the job’s route to the destination printer.

To have the printer retrieve and print jobs directly from PaperCut Cloud Services, configure Pull Delivery for a supported destination printer and enable the Cloud Node. The printer will retrieve and print jobs directly from the Cloud Node.

If Pull Delivery is not configured, at least one edge node on the network needs access to the printer to route and print the job. For more information, refer to Pull Delivery in PaperCut Hive.

When Pull Delivery cannot be used, PaperCut Hive or Pocket selects an edge node to relay the job to the destination printer. By default, the Autopilot algorithm attempts to select the most reliable client device to deliver the print job, which then relays the job.

In restricted network environments where user computers cannot communicate directly with the printers, apply Print Delivery Profiles to all printers. Grant dedicated, always-on edge nodes network access to the printers and configure them as the Individual selected clients for job release. This ensures that only the dedicated edge nodes are selected to route print jobs for release. For more information, refer to Autopilot - Overview and About Print Delivery Profiles.

Releasing jobs at the MFD

Releasing jobs from a mobile device

Releasing jobs from a mobile device using Print Offline

If the link to PaperCut Cloud Services is unavailable (for example, an Internet Service Provider outage), users can still release print jobs using their mobile device if:

• the Print Offline feature is enabled
• the mobile device is connected to Wi-Fi on the organization’s main network
• the mobile device can communicate with nearby edge nodes
• a nearby edge node stores a replicated copy of the job.

In restricted network environments where user computers can’t reach the printers, a dedicated edge node that the mobile device can reach is required to hold a replicated copy of the job. If no firewall ports are opened between user subnets and dedicated edge nodes (that is, the Cloud Node is exclusively relied on for routing jobs between subnets), Print Offline will not be available.

For more information, refer to About printing offline.

​​​​​​