Solved

LPR printing across IPSEC L2L tunnel problem.

Posted on 2008-10-30
9
1,143 Views
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.
0
Comment
Question by:NetSEng1
  • 4
  • 3
9 Comments
 
LVL 15

Expert Comment

by:bkepford
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.
0
 

Author Comment

by:NetSEng1
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.
0
 

Author Comment

by:NetSEng1
ID: 22847359
BTW-

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?
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 15

Expert Comment

by:bkepford
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.
0
 

Author Comment

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

Expert Comment

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

Accepted Solution

by:
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.
0

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Suggested Solutions

When you connect to your workplace's VPN, you may not notice that you are using your workplace's servers to serve up webpages.  This might be undesirable since the workplace can log all the places you've been.  It also might be very slow to load pag…
Overview Often, we set up VPN appliances where the connected clients are on a separate subnet and the company will have alternate internet connections and do not use this particular device as the gateway for certain servers or clients. In this case…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), 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…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), 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…

758 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

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now