LPR printing across IPSEC L2L tunnel problem.

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.
NetSEng1Asked:
Who is Participating?
 
bkepfordConnect With a Mentor Commented:
You should use the command "ip tcp adjust-mss 1300" on either side instead of the ip mtu.
0
 
bkepfordCommented:
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
 
NetSEng1Author Commented:
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
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
NetSEng1Author Commented:
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
 
bkepfordCommented:
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
 
NetSEng1Author Commented:
Would the "ip tcp path-mtu-discovery" be useful at all in this application?
0
 
bkepfordCommented:
Yes, good call. That should help if it is indeed an mtu problem.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.