We help IT Professionals succeed at work.

Cisco 871 to Netscreen 204 problem.

Last Modified: 2013-12-14
I have an remote site that currently has a DSL connection.  We have installed a Cisco 871 router and setup a VPN tunnel back to our corporate office here.  It connects to a Netscreen 204 appliance.  The VPN tunnel is up and running, but I am having issues with clients at the remote site.  The client machines are part of the 2003 AD, but there is no server at the remote site.  

The Cisco 871 is setup as a DHCP sever and it offers the DNS and WINS IP addresses of the server back here at the Corporate Office.  

Every 3-4 days, when a client logs in to the domain, it can take upwards of 10 minutes or more before they are actually able to start working on their machine.  It most cases, this can happen even if there is only one user up and running on the remote connection.

I have checked the config of both the Netscreen and the Cisco 871, and the only potentiial item that I can see that may affect it is the MTU.  The Netscreen is set 1500.  The Cisco by default is set to 1452 from what I can see.  Seeing that there are no issues with the actual tunnel connection, would these settings still have an impact for the client PC's at the remote site?
Watch Question


Further to this.....I have been mistaken.

The VLAN interface on the remote site has the ip tcp-mss adjust 1452, while the netscreen has the following (set flow tcp-mss 1500) in the config.
I doubt if it is a problem with MTU sizes, if that was the case then you should be able to see it throughout.

I would suggest to just install a DNS server at the remote location and it should take care of all the problems.

If you are encrypting the traffic over the VPN, MTU could be pretty significant because the packets sent by the netscreen (1500) can get chopped up to the lowest common denominator (1452). Obviously a router can't chop up an encrypted packet and piece it back together because you can't see in it... this is more usually an ISP router that would be causing the problem... but I'd change yours anyway to rule it out.

You don't use roaming profiles at this remote site do you? ... That could cause slow logons. DNS (as pointed out above) another obvious cause if the machine is just 'logging on' for large period of time.


Well here is what I have tried.

1.  On the Cisco 871 router, I have set the "ip tcp adjust-mss' to 1452 on both the VLAN internface and the WAN Interface.
2.  On a PC at the remote site, I have adjusted the MTU of the PC to 1452.
3.  On the Netscreen I have 'set flow tcp-mss' to 1452.
4.  On the PC at the remote site, I have entered an LMHOSTS entry for the domain to see if that speeds things up.

When ever I use the Cisco SDM to test the tunnel, I get the following error.

"A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets."

I have also set the 'crypto ipsec df-bit clear' globally on the Cisco 871 router, but yet I am still getting this message.

I have tried the 'crypto ipsec fragmentation after encryption' but this did not work.

I have other sites setup identical to this, and have tested the VPN tunnel.  While I do receive the same error message, I have more users at the other sites, and never have an issue with them loosing connections.  I have had the telco in to look at the DSL connection there, and they say that there are no issues on their end.  I am stuck at what to look at next?
I've had this same problem before between an NS and a Watchguard and it turned out the ISP (after denying vehemently for several days) finally admitted they had changed the MTU settings on an upstream router. We saw the output of this as delays in VPN traffic, and issues accesing websites over SSL from that office. Both caused by encrypted packets getting chopped up. The windows domain logon process is often encrypted (kerberos negotiation, etc) .. but regular traffic is not so this may explain why you are seeing a delay at that point.

"A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets."

This sounds a lot like an ISP router upstream of the office's NetScreen has an MTU lower than 1452. Get them to check the settings, or you could lower yours even further to 1400.

What might complicate this, is that if something in your LAN is sending encrypted packets larger than 1400, you may need to address that also.

Have a look at the last post in this thread, by Robing66066
This one is on us!
(Get your first solution completely free - no credit card required)
ping -l 1400 -f <other-side-ipofServer> ... Now try reducing slowly from 1400 to 1380, 1350 etc and see where it succeeds.

That is a really good suggestion (by rsivanandan).


I tried the ping -l 1400 -f <other-side-ipofServer>.  The test succeed.  I kept moving upward to 1425 where it failed.  So it did work at 1424.  That plus the 28 byte overhead for VPN, is why it is set to 1452.

I have sent an email to my ISP for the settings of their routers and MTU.  I will update you one my findings.
In the mean time, it wouldn't hurt doing a LMHOSTS test.



I tried the LMHOSTS solution.  While it did improve the login times, though not that greatly, I am still getting the error.
"A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets."

I am still waiting contact from my ISP.
If it improves the logon times, then definitely a DNS server at that location would help you out, no worries wait for the MTU thing to be over.



Still waiting from my ISP.  They have suggested a possible IOS upgrade, but I have to catch the router hanging again.


My ISP has advised me that the MTU on all of their devices is set to the default 1500.  The only thing that they suggested was to upgrade the IOS of the router at the affected location.  While I am skeptical that this is the fix, there is nothing else for me to go on.

However, the solution that Rajesh has mentioned did alleviate some of my problems (I have only heard from the user once since implementing the LMHOSTS file), I will award the points instead of leaving this post out there and out of date.

Thanks to all who replied.

Gain unlimited access to on-demand training courses with an Experts Exchange subscription.

Get Access
Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Empower Your Career
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

  • Troubleshooting
  • Research
  • Professional Opinions
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.