LPR printing across IPSEC L2L tunnel problem.

Posted on 2008-10-30
Last Modified: 2012-05-05
I have an odd problem that I can't seem to figure out. I have a Site-to-Site IPSec VPN tunnel setup between two Cisco 1841 routers. On the remote end there exists a windowsXP machine, an HP LaserJet printer, and a Mitel IP Phone. On the local end, there exists a unix based lpr print server with a queue that points to the IP of the remote printer, on port 9100.

The IP phone works, everything pings, the connectivity is good, and the latency end-to-end is less than 30ms with little jitter. From the Unix printer server on the local end, I can ping the printer, and I can telnet to the printer on ports 23 and 9100. The response on the ports of the printer does not lag nor hang.

The problem is that the printer won't print jobs sent to it from the LPR print server on the Unix server. The jobs just site in the print server queue, the printer does not show the blink light to signify that it is spooling. If I telnet to port 9100 on the printer, from the the printer server, and type some text, that prints.

A packet sniffer sitting on both ends shows packets leaving the printer server, the first 3 or 4 of which make it end to end in both directions, but the larger packets (1500 each) from the printer server don't make it. I set fragmentation on the crypto-map but it doesn't change anything. I set the mtu on the interfaces along the leg to as little 1000 (from 1500) and a few more packets get through, but the net result is still exactly the same.

Any ideas to fix this would be helpful.
Question by:NetSEng1
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
LVL 15

Expert Comment

ID: 22845637
This is just a guess but the print server may not just speak IP to the printer.
I would definately look at keeping the mtu below 1300.

Author Comment

ID: 22845836
I did a test ping from the print server to the printer, and it appears that the printer can't handle an mtu higher than 1300. I verified this by testing the same model printer on the local LAN, so the MTU limit being observed is a result of the printer and not the VPN connection. As a result of this, I set the MTU to 1300 and the problem still exists. The only difference I saw was that the packet sniffer on the remote end started seeing more "TCP segment lost" and "TCP transmissions" then when the MTU was set at 1400.

Author Comment

ID: 22847359

I am setting MTU by using "ip mtu <mtu integer>" command on each interface that has an IP address bound to it. Is this not the correct method for this? I also have the Cisco feature for fragmentation enabled so that fragmentation occurs before encryption.

The 1841 router on the remote end has a 4 port EtherSwitch EWIC card in it, and I am using a VLAN with a router IP on it in the router, through which the remote windowsXP workstation and the remote printer get their IP connectivity.

A packet sniffer capture shows that the printer server is sending 1300 byte packets as governed by the mtu setting.

The remote printer is still acting like it is getting bigger packets, although the packet sniffer on the remote end does show my traffic between the printer and the printer server.

I question if the VLAN or the EWIC is part of the problem.

Anyone have any other ideas? Need more info on the setup?
Connect further...control easier

With the ATEN CE624, you can now enjoy a high-quality visual experience powered by HDBaseT technology and the convenience of a single Cat6 cable to transmit uncompressed video with zero latency and multi-streaming for dual-view applications where remote access is required.

LVL 15

Expert Comment

ID: 22849931
You may go the other way on the fragmentation drop the MTU to 1200 for the link and then set the do not fragment bit.

Author Comment

ID: 22850909
Would the "ip tcp path-mtu-discovery" be useful at all in this application?
LVL 15

Expert Comment

ID: 22851044
Yes, good call. That should help if it is indeed an mtu problem.
LVL 15

Accepted Solution

bkepford earned 500 total points
ID: 23297483
You should use the command "ip tcp adjust-mss 1300" on either side instead of the ip mtu.

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

One of the Top 10  common Cisco VPN problems are not-matching shared keys. This is an easy one to fix, but not always easy to notice, see the case below. A simple IPsec tunnel between fast Ethernet interfaces of routers SW1 (f1/1) and R1(f0/0). …
I recently attended Cisco Live! in Las Vegas, a conference that boasted over 28,000 techies in attendance, and a week of hands-on learning hosted by a solid partner with which Concerto goes to market.  Every year, Cisco displays cutting-edge technol…
After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question