In the last weeks I was called by a customers, whose employees complained about SEP blocking them from using their printers in the home office.
What seems to be a piece of cake, turned out to be a little more difficult, after looking for the details.
The reason for the complexity is that many of the people reporting the problem were using printers that were built for end users, not enterprises.
As such, the manufacturers of the printers build machines that can be handled by people without deeper insight into IT.
In detail, there are two things that people need to do in order to operate a printer:
- Install the printer’s driver on the computer
- Send print jobs to the printer
Both operations require the computer to find the printer’s network interface. The problem is that many end users don’t really know (or at least care about) things like IP addresses. Therefore, the printer must be found by the computer by some kind of magic.
The magic here is using technologies like broadcast to detect the printer during the install process, as well as during each attempt to print later on. (Because the manufacturer of the printer needs to take care of dynamic IP addresses and other creepy stuff.)
Now, back to our situation:
The user tries to print a document at home, using his or her own printer. Since the printer driver cannot be sure that the printer’s got the same IP address as the last time it was used, it sends a broadcast call to all devices in the network, asking the printer to call back and say hello. Unfortunately, these broadcast packets are UDP packages that don’t “wait” for someone to send a feedback packet back like “well, I got your call, I’m your printer and you can reach me using the following IP”. No, UDP packets are just sent to the network without knowing if anyone is listening at all.
This leads to the problem that the answer from the printer is not seen as an answer to an existing request but rather as an independent attempt to initiate a conversation – and is therefore blocked by SEP, since we don’t allow incoming traffic.
So, what you need, is a firewall policy that allows incoming answers to UDP request packets send from the local computer to systems in the home office.
Here’s, what to do:
- Create a new rule in the firewall policy that your clients are using, when they’re outside your protected network.
- Configure the rule (with a meaningful name) to allow all traffic from all applications to any computer without logging.
- Double-click the Hosts field of the policy and change the remote computers to “local subnet”:
- Edit the new policy by double clicking on the protocol field and change the protocol from any to All UDP outbound:
- After closing the dialog, you can see, the protocol field now states “UDP outbound stateful”.
So SEP can allow traffic that by design doesn’t exist: answer packages to UDP requests.
- Save the policy.
It should look like this:
I hope, this policy will help you reducing the number of support calls.
Thanks for reading,