11-05-2008 12:11 PM
Hi folks -
I recently had an issue with two sites that had a site-2-site vpn tunnel between them. One site was hosting all the application servers (let's call this site A). All clients at site B (second site) were able to ping servers at site A using both the IP address and the DNS name. However, applications such as SAP and Outlook would not connect to the servers, even though ping was working fine. On some workstations, applications were working fine and on some, applications were not working fine. All workstations were running Windows XP SP2.
I entered the following command on the router at site B. The router was the VPN endpoint. After enterting this command, all workstations were able to connect to the applications successfully.
crypto ipsec df-bit clear
I believe this command clears the df bit setting from the client and allows the router to defragment the packet if needed. However, why were some clients able to connect to the applications and others not, even though they were running the same OS with the same Service Pack.
Would appreciate your thoughts?
11-08-2008 11:09 AM
The DF bit is to allow a user to specify there router to clear, set or copy the DF bit (Dont Fragment bit)from the encapsulated header, which basically determnines whether a router is allowed to fragment a packet so basically if the DF bit is set to clear, routers can fragment packets regardless of the original DF bit setting. HTH
11-09-2008 08:09 PM
Hi Kunal,
I think the problem is that the MTU size of the physical interface bearing your VPN tunnel is too small (probably the default 1500 bytes)
While the default ping generates 100 byte long packets and those get through the VPN tunnel easily, you applications like SAP send much larger packets.
SAP packets may even be 1500 bytes long.
Now if you add the tunnel overhead to these 1500 bytes, the resulting packet size may go up to 1600 bytes depending on encryption type, tunneling type etc.
You need to increase the MTU of the physical interface so it can forward those larger packets with the tunnel overhead.
e.g.:
interface s1/0
mtu 1600
When you applied the "crypto ipsec df-bit clear" command, you basically allowed fragmentation of packets that were too large for the configured MTU size.
This works fine but adds an unnecessary burden on the processor.
If you can increase the MTU of the physical interface, the packets will pass through it easily without fragmentation.
Cheers:
Istvan
11-10-2008 06:43 AM
Hi Istvan -
Thanks for your reply. I understand what you explained, but I am confused about the fact that some workstations were able to connect to the applications successfully and some were not. After making the change in the router for the df bit setting, all the workstations connected successfully.
All workstations have the same OS (Windows XP) and the same networking settings.
So not sure why some would work and some not.
11-10-2008 08:10 AM
you should not use the df-bit clear feature a a first option;
the goal should be to educate the hosts they should use smaller mtu size.
this should be done for tcp with
ip mtu 1412
ip tcp mss-adjust 1360
on the router's lan facing interfaces...
if your network is using lots of udp traffic
then you may have no choice but to allow some fragments and use the df-bit clear feature... again this should be a last resort. its never a good idea to have fragments at all.
-Joe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide