|
|
Paul, If you are bridging a tap device with a real ethernet NIC, then the mtu of the tap device must match the ethernet MTU which is 1500. When you add encryption and authentication overhead to that, a maximum packet size will be somewhat larger than that, which may cause packet fragmentation and reduce performance. One solution to the fragmentation issue that has been discussed on the CIPE list is to reduce the TCP MTU in the registry, so that TCP will use smaller packets which will not fragment. While I have not tried this personally, it is claimed that one could accomplish this by setting: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interface\ s\<interfaceid>\MTU = 1400 Where interfaceid is the ID of the TAP-Win32 device. This would only affect TCP connections over the tunnel from/to the registry-modified machine, not connections forwarded through the machine due to bridging or routing. Another potential solution to reducing fragmentation requires some coding -- it involves changing the setting of l_Adapter->m_MTU in tapdrvr.c. This would work for routed connections (not bridged). My original goal was to modify this driver setting via ioctl(), then allow the --tun-mtu or --udp-mtu options to automatically set it. Unfortunately, I ran up against a problem: the Windows kernel queries the TAP-Win32 driver for its MTU, long before OpenVPN is started or the TAP-Win32 adapter is opened. So for this to work, I would need to know how the tap driver can coerce the windows kernel to requery several OIDs (OID_GEN_MAXIMUM_FRAME_SIZE, OID_GEN_TRANSMIT_BLOCK_SIZE, and OID_GEN_TRANSMIT_BUFFER_SPACE), or even if this is possible. Also, make sure to enable compression as this will often reduce packet sizes enough to avoid fragmentation. If you want to see whether fragmentation is happening you can use tcpdump on *nix or windump/winpcap on windows to sniff the network. Let us know what you figure out. James Paul Sykes <paul.sykes@xxxxxxxxxx> said: > Hi, > > I have successfully set up an openvpn connection and bridged it to my > local network. However, I am now concerned about the performance of the > connection. The VPN connections are made to my PC over a DSL connection > from the internet to my VPN server. The security is only set up as a > simple key and compression is not enabled. > > As I am fairly new to terms such as mtu I am not entirely sure what I > should set them to. I know that the optimal mtu for my dsl connection > is apparently 1458, and when I run the openvpn program it comes up > saying the total link mtu is 1608. Presumably this a tun-mtu of 1500 > plus the 64 and 44 overheads that I have seen are defaults. Should the > mtu not be set so that the maximum it can be is 1458? If so what is the > best way of doing this. Could I use link-mtu 1458, but I have read that > this is not the command to use with TAP devices (I am running the VPNs > on Windows XP computers) or should I set the tun-mtu to 1350 which would > give a total of 1458 with the overheads. Lastly should I change the > values for the overheads, I know that the 64 byte overhead can be set by > the tun-mtu-extra setting and should apparently be 64 for TAP devices, > but I can't remember where I read about the overhead that is equal to 44 > bytes. > > The only reason I am concerned about the speed of the connection is > because when I ping the remote computer directly over the internet it > usually has a ping of 20ms and when I ping it over the tunnel it is > variable and anything from 30 to 70+ ms. Plus the maximum transfer rate > I have managed to get so far is about 30k/s when the DSL link is capable > of 60k/s (the DSL link is only at my end, the remote node is connected > via a fast university link, and I am trying to transfer files from the > remote node to my network). > > I have also read about using the ping -s command to check for > fragmentation, but ping -s on a windows pc gives you the timestamp for > count hops and doesn't change the size of the packet. > > If anybody can help me with the settings that optimise an OpenVPN link I > would be most grateful. > > Paul > -- ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |