Certain PostScript prints from SAP cause flood on RPM server

Question

This situation may be a little localised, but the root of the problem means that it may happen as long as you're passing PostScript (and possibly other types of print jobs) through a firewall with application control or a similar feature turned on (say, because you have a VPN tunnel to a remote site).

We run Brooks RPM on a desktop machine to accept PostScript print jobs from our SAP server. Basically, it applies a script to convert the input (a PostScript file) to PDF, give it a nice name, and send it to the user's email address with a pre-formatted subject line for ease of forwarding. The SAP server is physically located at our site. I have SAP users here and at a remote site, which we are connected to via a VPN tunnel (details of the connection are irrelevant).

Once in a while, certain documents were sending infinitely repeated print jobs to the server when they were printed. The symptoms were as follows:

• More than one type of document had the problem
• The error could be reproduced consistently on the "problem" documents
• The printout was incomplete, but interestingly each copy of the print job had a different state of incompleteness
• The problem only occurred at the remote site
• From both ends, network traffic looked totally normal (i.e. no dropped packets etc.), and no other print jobs were having problems

To fix the problem, we had to stop the Windows Printer Spool service, clear out %WINDIR%\system32\spool\PRINTERS and restart the Printer Spool service - only then would the repeated print jobs stop. I found it totally weird that the printouts would have different content each time - I guessed that the SAP server was consistently producing malformed PostScript files in response to each failure report from the print server, but this was disproved when we checked the SAP printer spool log - there was only one output on record for each print attempt. From my (admittedly lacking) understanding of print spooling, the print jobs should not then have had different content each time since the content was not actually being regenerated.

It turns out I was half right - the print jobs were mangled, but not by SAP.

Answer 1

tl;dr version: It was SonicWALL App Control.

The guy who wrote the script, the remote site admin, my boss and I sat down at my site to work out the problem. We managed to isolate the problem to something happening in transit - a sample PS file in the RPM server's spool was corrupted, but the matching PS file on the client's printer spool was perfectly fine when we converted it to PDF. Furthermore, using the remote site admin's laptop (remember, he was with us at my site) to print a problem document did not trigger a flood.

We triggered a flood from a remote machine and did a network check again - traffic looked totally normal. Then the remote site admin took a look at an unrelated log and saw something totally off:

It turns out that SonicWALL App Control was incorrectly identifying the print jobs' traffic as an IM file transfer and cutting the connection upon detection - this explains the inconsistency of the print jobs' content. Once we whitelisted our print server on the firewall, the problem disappeared.

It seems obvious now, but hindsight is 20/20.

So, in summary: if you're having trouble with print jobs that pass through a firewall, check if they're being picked up by any sort of application filtering.