Printer over Sonicwall VPN

We setup a Sonicwall VPN tunnel between two locations.  In one location we have a workstation and a printer.  At the other location, we have the print server.  I can ping from both sides and all the data that needs to flow thru is working fine.

However, we are struggling to get print jobs to work.  They seem to work sporadically at best.

The print job will get to the print server and either work fine or it just sits in the queue until it errors out. It doesn't appear to be a traffic issue as there is almost no traffic across the VPN.
I’m not sure what I need to do to get that print job to go back across the tunnel every time.  Thanks.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Have you verified the network settings in both the print server and the printer itself, make sure your default gateway information is correct on both of them
cames01Author Commented:
yes, everything looks fine.  I can ping back and forth across the tunnel with no issues.  Sometimes the print job does work fine.

As I said, the ping always works.  However, the HTTP interface on the printer doesn't always come up.  If I'm on the print server side, I can only bring up the HTTP interface when the print jobs are working.  

So, that has me thinking it's something with the VPN and the print job is timing out.  I don't know if there is a rule or something that I can add to force the jobs back to the printer.  Or a timeout somewhere that I can increase.
wyliecoyoteukIT directorCommented:
Try setting the spooling to "start printing after the last page has spooled" (printer properties>advanced tab).
Otherwise the printer may time out on multi-page jobs.
you could also try changing the port type, if it is raw, try lpr (the queuename will vary depending on the printer, but port1 or print often work)

there may be a timeout setting on the printer, on some you can also increase the data buffer size, depends on model.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MSSPs - Are you paying too much?

WEBINAR: Managed security service providers often deploy & manage products from a variety of solution vendors. But is this really the best approach when it comes to saving time AND money? Join us on Aug. 15th to learn how you can improve your total cost of ownership today!

Blue Street TechLast KnightCommented:
Hi cames01,

What is the Model & firmware version of your SonicWALL?

Some Microsoft networking environments rely heavily on NetBIOS broadcasts to advertise and locate network resources (servers, print devices, etc). On a local LAN segment, this works fine, as broadcasts are propagated to every node on the local segment. When the network segments are separated, this mechanism fails, since firewalls generally are not configured to forward broadcasts to remote segments. And users are accustomed to finding these resources by clicking on the ‘Network Neighborhood’ or ‘My Network Places’ desktop icons, or by a mapped drive to the resources.

By default, SonicWALL devices are configured to not pass Microsoft NetBIOS broadcasts across interfaces. Below, we will detail how to configure the SonicWALL to pass these broadcasts over the VPN.

Note: In larger environments, these additional broadcasts may lead to a substantial increase in traffic, and this may not be recommended. Instead, it is recommended that the Microsoft networking environment be correctly configured using Active Directory and/or WINS services, which are components of Microsoft’s Windows Server.


Are you running AD at the environment? If so, correct use of AD and/or WINS will minimize issues when attempting to access Microsoft network resources across interfaces. Please refer to;en-us;160177 for a more detailed discussion of this topic. (It's an old article but it still applies)

The following checklist may help resolve printing over VPN issues:

1. Ensure that the printer has been configured and the local computers are able to print on the printer.
2. Ensure that the VPN connection is established.
3. Test the VPN tunnel to insure you are able to access other network resources behind the remote LAN.
4. Enable NetBIOS on the VPN policies.

In SonicOS Standard, Uncheck “Disable all VPN Windows Networking (NetBIOS) Broadcasts” under the VPN > Advanced page before proceeding to the next step.)

In the VPN > Settings page click the edit icon under Configure for the VPN policy name you want to edit. The VPN Policy window is displayed.
Click on the Advanced tab.
Check the option Enable Windows Networking (NetBIOS) broadcast.
Click OK.

In SonicOS Enhanced, VPN Policies will auto-create IP Helper NetBIOS relay policies if the "Enable Windows Networking (NetBIOS) Broadcast" checkbox is selected on the "Advanced" tab of the VPN Policy.

Let me know how it goes!
To clarify:
  PC1 exists and site 2
  Printer1 exists at site 2
  Print Server1 exists at site 1
The desire is to print from PC1 to Printer1 via Print Server1 ???  The error is that the print jobs are hanging in the Print Server1 print queue for Printer1 ??

  If that is the case, please let me know the OS version of Print Server1 and the make\model of Printer1 and I can provide some detailed instructions.
cames01Author Commented:
Thanks everybody for all the feedback.  I’m going to make some of the changes today starting with the printer suggestions.  

To answer a few of the questions:

Firewall – Sonicwall NSA 250 on the print server side
Another Sonicwall (not sure what the model) was setup on the remote side

Printer is a Dell 2335dn

OS on print server is Windows Server 2003 R2.  

Site 1 =  print server
Site 2 = PC and printer

VPN  between the sites

I can ping back and forth.

The print job always makes it from site 2 to site 1.  However, it doesn’t always return to site 2.  Sometimes it prints fine.  Other times it errors out in the print queue at site 1.  

Please continue any suggestions that you have and I will report back.  Thanks, again.
I would recommend changing the output from the print server queue to use LPR (port 515) instead of standard TCP/IP (port 9100) printing.

  1- Go to the print server
  2- Open the Printer Properties for the printer at site 2
  3- Click on the Ports tab
  4- Click on Configure Port
  5- Click on LPR
  6- Enter "raw" for the queue name (without the quotes)
  7- Check LPR Byte Counting Enabled
  8- Uncheck SNMP Status Enabled
  9- Click on OK
10- Uncheck Enable bidirectional support
11- Click on Close

Notes:  This should allow the print jobs to flow smoothly from the print server to the printer as long as port 515 is open on the VPN connection between site 1 and site 2
cames01Author Commented:
Here is the follow up:

Yesterday I changed the printer to start printing immediately and was able to print all day long.  Today, the print jobs are back to being stuck in queue.  so, I changed the queue to use LPR but still had no luck.

I then went and tried to edit the VPN policy to include netBIOS but ran into problem there.  The site with the computer/printer is setup to get DHCP from the site with the print server.  So, it doesn't appear that I'm able to use the netBIOS option.

I will check back to make sure I haven't missed an suggestions but still struggling on this end to figure out what is so hit or miss about these print jobs.
Blue Street TechLast KnightCommented:
Did you read my entire post (http:#a39485128) ? Are you running AD? I believe it addresses your issue to a T.

Let me know if I'm missing something or what occurs when you try to enable NetBIOS.

Once the port is changed to LPR on the outbound side of the queue, it only utilizes TCP port 515 to send the print jobs.

  If you suspect that the print jobs are getting corrupted on the way into the print server's queue, then I would recommend also changing the incoming side to LPR.  That totally removes any AD issues from the entire printing picture.

  Let me know the OS version of the PC at site 2 and I can provide specific instructions.
Blue Street TechLast KnightCommented:
Any update on this?

If you haven't done so already tailor your MTU by decrementing it by 8 starting at 1500 until you get 0% loss. Open cmd prompt and use 'Ping -f -l 1500' to test. Here is a step-by-step:
cames01Author Commented:
Thanks, no real update yet.  It has been working all week so I've held off making any changes.  I'm sort of in wait and see mode.  When it goes down again then I will make the next set of recommended changes.  Thanks.
Blue Street TechLast KnightCommented:
OK, sounds good.
cames01Author Commented:
We are still holding steady however we are going to move the user to another location so I've decided to just install the printer locally instead of going thru all the trouble for a short term problem.  I do feel that many of the answers above were correct and helped me along the way.  So, I hope everybody is ok with me splitting the points.  Thanks to all
Blue Street TechLast KnightCommented:
Glad I could help! Thanks for the points.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.