Printing via DMZ and into masked networks
Introduction
In contrast to the usual communication direction, ThinPrint Connection Service builds a secure print tunnel from a ThinPrint Client in any branch office to the central ThinPrint print system in the data center – the ThinPrint Secure Tunnel.
This clever design has an important advantage in that the central ThinPrint Engine acting as a print server doesn’t need to know the IP addresses of the network printers located in the branch offices. In most branch offices, masked networks are used and a VPN tunnel is necessary to reach printers. With ThinPrint, this is not necessary as the ThinPrint Secure Tunnel takes on this task, specifically for printing. Print jobs are delivered to branch offices via this tunnel and then distributed to network printers via the ThinPrint Client. A direct connection from the central ThinPrint Engine to the printers is not necessary. In addition, print data can be securely transmitted thanks to encryption, an important feature as print data contains information just as sensitive as on printed documents.
The easiest option to roll out the ThinPrint Client with Connection Service is with ThinPrint Hub, a small, yet high-performance print hardware device from ThinPrint upon which the ThinPrint Client is preinstalled. The ThinPrint Hub can be centrally configured. Once sent to branch office, it needs only to be connected to a power supply and a network cable thanks to its plug-&-play design. There is no limit to the number of network printers that can be connected to the ThinPrint Hub. Additionally, four USB printers can be connected and effectively turned into network printers.
Furthermore the Connection Service is the perfect DMZ component for printing. TCP ports need only be opened towards the Connection Service and no data is stored or spooled locally.
The example in section Sample configuration illustrates a test installation of the Connection Service. Once you are convinced of the software's functionality, the installation can be adapted to your requirements.
Standard ThinPrint scenario
In a normal setting, ThinPrint Engine is installed on a remote desktop (terminal server or virtual desktop), or on a central print server. When a user initiates a print job, ThinPrint Engine compresses and encrypts the print data and streams it (in packets of some KB) across a preset bandwidth to the ThinPrint Client.
ThinPrint Client decompresses and decrypts the print data and forwards it to the correct print interface. If ThinPrint Output Gateway (Driver Free Printing) is used on the server, rather than an original printer driver, ThinPrint Client Windows feeds the print data into the Windows print process so that the data is rendered on the client machine with the original printer driver.
Printing via DMZ and into masked networks
So that the ThinPrint Client does not have to be installed on every end device in a remote office, it is sufficient for it to be installed on a local print server. Alternatively the ThinPrint Hub can be used. The ThinPrint Client installed there receives all print data, decompresses and decrypts it and then distributes it conventionally through the office network. Here again, NAT poses no problem as the Connection Service resolves any NAT related issues: The ThinPrint Client connects to the Connection Service, therefore establishing a connection through which print jobs can be sent despite NAT.
This scenario can be used beyond just Windows environments. All required printers are installed in V-Layer mode on a central print server. With these printers, it is possible to print in any Unix, SAP, AS/400 or iSeries system. The ThinPrint Engine installed on the central print server compresses and encrypts the print data and sends it over controlled bandwidth to the ThinPrint Client.
In addition, the printers, including Connection Service Ports and drivers can be created on the central print server, using the Management Services.
