My company has two sites, each with their own LAN, using site to site VPN tunnel to connect the two sites.
When transferring files (especially larger files) from site1 to site2 server1, the file transfer fails. I don't think this can be a VPN issue because transferring the same files to site2 server2 which is on the same network as server1 works fine.
Pings to server1 and server2 at site2 from site1 are about the same, mostly 19/20ms with the odd one up to 50ms.
As server1 is DB server with a high load I thought the NIC maybe overloaded, but a transfer from site2 server1 to site2 server2 works fine, and that uses the same NIC on server1 as transfers from site1 to site2 server1.
The servers are both Windows Server 2003 VMs with VMXNET 3 NICs.
Site2 Server1 route print:
IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 50 56 99 28 9b ...... vmxnet3 Ethernet Adapter #2
0x10004 ...00 50 56 99 18 97 ...... vmxnet3 Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.20.10.1 172.20.10.18 10
10.10.10.0 255.255.255.0 10.10.10.70 10.10.10.70 10
10.10.10.70 255.255.255.255 127.0.0.1 127.0.0.1 10
10.255.255.255 255.255.255.255 10.10.10.70 10.10.10.70 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.20.10.0 255.255.255.0 172.20.10.18 172.20.10.18 10
172.20.10.18 255.255.255.255 127.0.0.1 127.0.0.1 10
172.20.255.255 255.255.255.255 172.20.10.18 172.20.10.18 10
224.0.0.0 240.0.0.0 10.10.10.70 10.10.10.70 10
224.0.0.0 240.0.0.0 172.20.10.18 172.20.10.18 10
255.255.255.255 255.255.255.255 10.10.10.70 10.10.10.70 1
255.255.255.255 255.255.255.255 172.20.10.18 172.20.10.18 1
Default Gateway: 172.20.10.1
===========================================================================
Persistent Routes:
None
Site2 Server2 route print
IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 50 56 99 15 00 ...... vmxnet3 Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.20.10.1 172.20.10.114 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.20.10.0 255.255.255.0 172.20.10.114 172.20.10.114 10
172.20.10.114 255.255.255.255 127.0.0.1 127.0.0.1 10
172.20.255.255 255.255.255.255 172.20.10.114 172.20.10.114 10
224.0.0.0 240.0.0.0 172.20.10.114 172.20.10.114 10
255.255.255.255 255.255.255.255 172.20.10.114 172.20.10.114 1
Default Gateway: 172.20.10.1
===========================================================================
Persistent Routes:
None
Site1 Server route print:
===========================================================================
Interface List
14...00 50 56 93 00 0b ......vmxnet3 Ethernet Adapter #2
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.168.1 192.168.168.118 261
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.168.0 255.255.255.0 On-link 192.168.168.118 261
192.168.168.118 255.255.255.255 On-link 192.168.168.118 261
192.168.168.255 255.255.255.255 On-link 192.168.168.118 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.168.118 261
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.168.118 261
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 192.168.168.1 Default
===========================================================================
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 306 ::1/128 On-link
14 261 fe80::/64 On-link
14 261 fe80::3c6b:996f:ef36:ee76/128
On-link
1 306 ff00::/8 On-link
14 261 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
tracert from site1 to site2 server1:
Tracing route to server1 [172.20.10.18]
over a maximum of 30 hops:
1 19 ms 19 ms 19 ms server1 [172.20.10.18]
Trace complete.
tracert from site2 server1 to site1:
When this was run it went to the external IP of site2, then to a couple of external ips of the isp, then times out.
Can anyone suggest any troubleshooting steps?
Thanks, Charlotte.
Best Answer
Here's a dirty hack to figure out your MTU. Start by looking at your current MTU setting. Open a command prompt with Administrative privledges and then run the command as follows:
You'll see something like:
With that knowledge you'll note that your MTU is currently set to 1500. If that's what your ISP works with... you should be able to ping sites like msn.com or google.com with a packet size of 1500 without fragmenting the packet.
If you see an error message like:
Packet needs to be fragmented but DF set.You know you need to go smaller. So, subtract 8 & try again... until you find a valid MTU. Once you find the one that gives you a reply without complaining about needing to be fragmented... it's time to change your MTU. Back to the admin command prompt... and we do this: (replace 1464 with whatever you came up with)If you just want to test this out... without committing changes... skip the store=persistent bit... and a reboot will set it back the way it was. You can also manually set it back to whatever you started with...
Once you know what your ISP's MTU is... you should then do the same for any tunnel-interfaces you have. VPN tunnels add their overhead and so the usable MTU is a few bytes less. If you're using a hardware VPN gateway of some sort, it may automatically set the MTU... and you may not be able to set it manually.
Keep in mind, that I also did not address "jumbo frames"... which can have a MTU of 9000 or more. Most ISPs do not allow jumbo-frames unless you have a higher end business account.
I don't know if that will work for everyone... but it "worked for me" (c)