[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Windows client, mysterious routes and MTU issues


  • Subject: Re: [Openvpn-users] Windows client, mysterious routes and MTU issues
  • From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 04 Feb 2006 23:57:18 -0500

On Sat, 2006-02-04 at 18:02 -0500, John A. Sullivan III wrote:
> Hello, all.  We are seeing some bizarre behavior with our Windows
> OpenVPN clients.  We are not seeing the same behavior in the Linux
> clients.  Our setup is an OpenVPN gateway running openswan connecting to
> other offices via openswan.  I am just now beginning to peruse the more
> obscure configuration settings and do some extensive testing but, if
> anyone knows the answer off the top of their head, it will save me many
> hours.
> 
> Whenever the windows client accesses a station in one of the offices,
> i.e., across the openswan VPN, an entry for that station is added to the
> Windows routing table.  Although that is surprising, it would not be too
> bad except that the MTU on the route is set to 576! The result is
> massive packet fragmentation.
> 
> This happens without or without using the fragment directive.  The
> routing entries are not made when using a Linux client.  So, for
> example, when the windows client first connects, they can do:
> 
> ping -f -l 1472 x.x.x.x
> 
> After a moment, the route is added and the same command fails until the
> length is reduced to 548 or lower.
> 
> We are using 2.1 beta8.  The client config is:
> 
> client
> dev tun
> proto udp
> remote x.x.x.x 1194
> resolv-retry infinite
> nobind
> ca /etc/openvpn/certs/NiagaraCA.pem
> pkcs12 /etc/openvpn/certs/jsullivan.atlas.p12
> ns-cert-type server
> tls-auth tlsauthniag 1
> comp-lzo
> verb 3
> #fragment 1435
> #mssfix
> passtos
> 
> The server config is:
> 
> port 1194
> proto udp
> dev tun0
> key /etc/ipsec.d/private/niagararasgwk.pem
> cert /etc/ipsec.d/certs/niagararasgwc.pem
> ca /etc/ipsec.d/cacerts/NiagaraCA.pem
> crl-verify /etc/ipsec.d/crls/NiagaraCRL.pem
> dh /etc/openvpn/certs/dh5.pem
> server 172.20.100.0 255.255.255.128
> topology subnet
> ifconfig-pool-persist ipp.txt
> client-connect /etc/openvpn/clientconn.script
> client-disconnect /etc/openvpn/clientdisconn.script
> push "redirect-gateway def1"
> push "dhcp-option DNS 10.4.1.77"
> push "dhcp-option DNS 10.1.1.22"
> push "dhcp-option DNS x.x.x.x"
> push "dhcp-option WINS 10.1.1.10"
> push "dhcp-option WINS 10.4.1.35"
> keepalive 10 120
> tls-auth /etc/openvpn/tlsauthniag 0 # This file is secret
> comp-lzo
> persist-key
> persist-tun
> status /var/log/openvpn/openvpn-status.log
> log-append  /var/log/openvpn/openvpn.log
> verb 3
> passtos
> management 127.0.0.1 1194 /etc/openvpn/mgmtfile
> 
> The tricky thing with these kinds of problems is that everything
> actually works and no one would know the worse if we hadn't seen the
> fragmentation messages.  Now that we know, we know we can make a
> dramatic improvement in performance if we can fix this.  Thanks - John

Well, I've tried just about everything I could think of to no avail.  I
tried:
using mtu-test
using mtu-disc (windows didn't like it)
setting mssfix
setting tun-mtu
both different route-methods

setting EnablePMTUDiscovery to 1 in the Windows registry instead of just
assuming it as default
setting EnableBHDiscovery (or whatever Black Hole discovery is) to 0
setting an MTU in the Windows registry

At first, I could not reproduce the problem locally because I was only
pinging. I found I could do 1472 byte non-fragmented pings just fine.
However, as soon as I tried to use a TCP protocol, a route was added to
the routing table and its MTU was set to 576.  I do not know why TCP
traffic provokes this change.

I do not know why it makes a route entry and I do not know why it uses
576 MTU.  I do know that is the Windows default for non-local networks
when PMTU is disabled.

Alas, this has cost me a good 15 hours today.  If anyone can shed any
light on the topic, I'd greatly appreciate it.  I would guess this is a
problem degrading the performance of many OpenVPN installations and we
just don't realize it because the applications all work.  Thanks all -
John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@xxxxxxxxxxxxxxxxxxx

Financially sustainable open source development
http://www.opensourcedevel.com


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Warning: require_once(../../../archive_common.php) [function.require-once]: failed to open stream: No such file or directory in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2006-02/msg00065.html on line 290

Fatal error: require_once() [function.require]: Failed opening required '../../../archive_common.php' (include_path='/usr/local/lib/php') in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2006-02/msg00065.html on line 290