Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Your test isn't consistent. Copying files from site2 server1 to site2 server2 isn't the same as copying from site2 server2 to site2 server1. Your problem is copying TO site2 server1, any test that tests copying FROM site2 server1 is not replicating the conditions of the problem. All of your tests should involve copying TO site2 server1, not copying FROM site2 server1. –  joeqwerty Nov 1 '12 at 15:13
1  
Without more information about actual configuration of the interfaces, there's a very-long list of things it could be. Does that server have multiple default gateways? Are metrics set incorrectly? Do you have static-routes? What is the ping statistics using the maximum MTU for the links? What method are you using for transferring files? ... the list goes on. –  TheCompWiz Nov 1 '12 at 15:20
    
@joeqwerty OK I see what you mean but the test I ran to confirm the problem wasn't the VPN tunnel was to copy files FROM site1 TO a different server at site2, on the same network as server1, which worked fine. –  Charlotte Nov 1 '12 at 15:27
    
@TheCompWiz Thanks for that, I'm an accidental network admin so that's exactly the sort of stuff I was looking for. To answer your questions: server has two nics, one on the DMZ with no default gateway and one on the LAN with one default gateway, so no, it does not have multiple default gateways. I have no idea if the metrics are set correctly, how do I check this? If static route is the same as persistant route then no, the routes are not static. I'm not sure how to check the ping statistics using the max MTU for the links but will find out and report back. –  Charlotte Nov 1 '12 at 15:31
    
@Charlotte Can you include a copy of the routing tables from the two machines in question and perhaps a tracert? (at the cmd prompt do a "route print" and "tracert x.x.x.x" with x.x.x.x being the "other" server) Also, don't forget the PINGs at the max MTU for the link. –  TheCompWiz Nov 1 '12 at 15:39

1 Answer 1

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:

netsh interface ipv4 show subinterfaces

You'll see something like:

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  1500                1  8864896253  1116506364  Local Area Connection

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.

ping www.google.com -f -l 1500

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)

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1464 store=persistent

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)

share|improve this answer
    
OK, I found the MTU for the server on site1, it is 1500 and when pinging site2 server1 with 1500 MTU I got 'Packet needs to be fragmented but DF set', it works OK with MTU 1464. When trying to get the MTU on site2 server1 i get: The following command was not found: interface ipv4 show subinterfaces –  Charlotte Nov 1 '12 at 16:05
    
you forgot 'netsh' ... which is the command. His code example has a scroll bar. –  Safado Nov 1 '12 at 16:09
    
No I included netsh but no joy...anyway I'm going to try setting the MTU on the server that I'm transferring the files FROM and see if that helps. –  Charlotte Nov 1 '12 at 16:13
    
I wouldn't suggest setting it blindly. netsh should be part of windows 2003... what error did you get? –  TheCompWiz Nov 1 '12 at 16:15
    
@Charlotte - I see that Site2 Server1 is multihomed. What's the purpose of that? What are you changing the MTU from and to? 1500 is the standard MTU for a Windows box and I'd suggest that changing it to something else is only obfuscating the issue. Don't try fixing what should be a standard problem by changing to non-standard settings. –  joeqwerty Nov 1 '12 at 16:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.