Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 39 subscribers
  • Views 8971 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN poor performance with Office files on SMB shares, probably because of MTU issues

LHerzog

Hi,

some users are complaining very bad SMB performance when using SSL VPN (TCP) to our XG 18 MR4.

Our diagnosis so far is, that DS-Lite Internet users are affected by the bad performance only. Like Unitymedia / Vodafone Cable.

Users with DSL lines like Telekom without IP-Sharing ot NAT, are not affected.

Location: Germany

The issue can be noticed when opening a 10 kb MS Office file from an SMB share in the tunnel takes about 30-40 sec to open on DS-Lite, <5 sec on non-DS-Lite.

Opening a 1MB Text file from the same SMB share takes 10 sec on DS-Lite, ~5 Sec on non-DS-Lite.

Strange fact: downloading a large file from the same SMB share is almost the same on DS-Lite and non-DS-Lite.

What I can see in wireshark, is that the MTU is smaller on the DS-Lite side than on our XG firewall. The firewall uses 1500, the VPN client uses 1392.

When opening one file from a SMB folder, all other files are also touched by the client and it looks like, they are fully transferred.

This is what downloading a 500 MB iso-file from the tunnel SMB share to the local machine looks like on DS-Lite. Performance is really OK. Nothing to complain about:



This thread was automatically locked due to age.
  • 0

    OK, I forgot my question, can I tune the client by some settings in the ovpn file on the client without touching the XG side?

    I tested with link-mtu 1200 and I could see that setting used in the log but causing packet loss.

    Tue Feb 02 13:09:29 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1200', remote='link-mtu 1572'
    Tue Feb 02 13:09:29 2021 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1128', remote='tun-mtu 1500'

    Any other tuning possible?

  • 0 in reply to LHerzog

    this is what the TCP Dump on the XG looks like for probably all of our SSL VPN users. This does not look good.

    It is always one good packed, followed by 2 duplicate packets or retransmits.

    No.		Time			Source			Destination		Protocol SrcPort DstPort	Length	Info
6086	17:06:18,228592	Firewall-IP		Client-WAN-IP	TCP	443		40244	1480	[TCP Retransmission] 443 → 40244 [ACK] Seq=916350 Ack=121799 Win=11057 Len=1420
6087	17:06:18,228592	Firewall-IP		Client-WAN-IP	TCP	443		40244	1480	[TCP Retransmission] 443 → 40244 [ACK] Seq=916350 Ack=121799 Win=11057 Len=1420
6088	17:06:18,242402	Client-WAN-IP	Firewall-IP		TCP	40244	443		66		40244 → 443 [ACK] Seq=121799 Ack=914930 Win=12425 Len=0
6089	17:06:18,242402	Client-WAN-IP	Firewall-IP		TCP	40244	443		66		[TCP Dup ACK 6088#1] 40244 → 443 [ACK] Seq=121799 Ack=914930 Win=12425 Len=0
6090	17:06:18,242402	Client-WAN-IP	Firewall-IP		TCP	40244	443		62		[TCP Dup ACK 6088#2] 40244 → 443 [ACK] Seq=121799 Ack=914930 Win=12425 Len=0
6091	17:06:18,242409	Firewall-IP		Client-WAN-IP	SSL	443		40244	217		Continuation Data
6092	17:06:18,242410	Firewall-IP		Client-WAN-IP	TCP	443		40244	221		[TCP Retransmission] 443 → 40244 [PSH, ACK] Seq=917770 Ack=121799 Win=11057 Len=161
6093	17:06:18,242410	Firewall-IP		Client-WAN-IP	TCP	443		40244	221		[TCP Retransmission] 443 → 40244 [PSH, ACK] Seq=917770 Ack=121799 Win=11057 Len=161
6094	17:06:18,246997	Client-WAN-IP	Firewall-IP		TCP	40244	443		66		40244 → 443 [ACK] Seq=121799 Ack=917770 Win=12425 Len=0
6095	17:06:18,246997	Client-WAN-IP	Firewall-IP		TCP	40244	443		66		[TCP Dup ACK 6094#1] 40244 → 443 [ACK] Seq=121799 Ack=917770 Win=12425 Len=0
6096	17:06:18,246997	Client-WAN-IP	Firewall-IP		TCP	40244	443		62		[TCP Dup ACK 6094#2] 40244 → 443 [ACK] Seq=121799 Ack=917770 Win=12425 Len=0
6097	17:06:18,247006	Client-WAN-IP	Firewall-IP		SSL	40244	443		159		Continuation Data
6098	17:06:18,247006	Client-WAN-IP	Firewall-IP		SSL	40244	443		159		[TCP Fast Retransmission] , Continuation Data
6099	17:06:18,247006	Client-WAN-IP	Firewall-IP		SSL	40244	443		155		[TCP Fast Retransmission] , Continuation Data
6100	17:06:18,288254	Firewall-IP		Client-WAN-IP	TCP	443		40244	56		443 → 40244 [ACK] Seq=917931 Ack=121898 Win=11057 Len=0
6101	17:06:18,288256	Firewall-IP		Client-WAN-IP	TCP	443		40244	60		[TCP Dup ACK 6100#1] 443 → 40244 [ACK] Seq=917931 Ack=121898 Win=11057 Len=0
6102	17:06:18,288259	Firewall-IP		Client-WAN-IP	TCP	443		40244	60		[TCP Dup ACK 6100#2] 443 → 40244 [ACK] Seq=917931 Ack=121898 Win=11057 Len=0
6103	17:06:18,295564	Client-WAN-IP	Firewall-IP		TCP	40244	443		66		40244 → 443 [ACK] Seq=121898 Ack=917931 Win=12424 Len=0
6104	17:06:18,295564	Client-WAN-IP	Firewall-IP		TCP	40244	443		66		[TCP Dup ACK 6103#1] 40244 → 443 [ACK] Seq=121898 Ack=917931 Win=12424 Len=0
6105	17:06:18,295564	Client-WAN-IP	Firewall-IP		TCP	40244	443		62		[TCP Dup ACK 6103#2] 40244 → 443 [ACK] Seq=121898 Ack=917931 Win=12424 Len=0
6106	17:06:18,309973	Client-WAN-IP	Firewall-IP		SSL	40244	443		386		Continuation Data
6107	17:06:18,309973	Client-WAN-IP	Firewall-IP		TCP	40244	443		386		[TCP Retransmission] 40244 → 443 [PSH, ACK] Seq=121898 Ack=917931 Win=12424 Len=326
6108	17:06:18,309973	Client-WAN-IP	Firewall-IP		TCP	40244	443		382		[TCP Retransmission] 40244 → 443 [PSH, ACK] Seq=121898 Ack=917931 Win=12424 Len=326
6109	17:06:18,309986	Firewall-IP		Client-WAN-IP	TCP	443		40244	56		443 → 40244 [ACK] Seq=917931 Ack=122224 Win=11057 Len=0
6110	17:06:18,309987	Firewall-IP		Client-WAN-IP	TCP	443		40244	60		[TCP Dup ACK 6109#1] 443 → 40244 [ACK] Seq=917931 Ack=122224 Win=11057 Len=0
6111	17:06:18,309987	Firewall-IP		Client-WAN-IP	TCP	443		40244	60		[TCP Dup ACK 6109#2] 443 → 40244 [ACK] Seq=917931 Ack=122224 Win=11057 Len=0
6112	17:06:18,310273	Firewall-IP		Client-WAN-IP	SSL	443		40244	1499	Continuation Data

  • 0 in reply to LHerzog

    It is surely somehow related to MTU size as those Unitymedia DS-Lite lines have 40 byte overhead compared to those not using DS-Lite. So we have intransparent packet splitting and lost responses as the VPN client "thinks" it can use 1500.

    A non fragmented ICMP is only possible with 1432 byte ping to WAN from affected clients. Usual size would be 1472.
    Due to VPN MTU currently set at 1500, the client is virtually able to ping hosts into the tunnel with 1472 byte unfragmented.

    Will check our options with support.

    But the fact that transferring huge files over the VPN is currently quite quick does not match the reported problems with the small office files and MTU issues.

  • 0 in reply to LHerzog

    Hello,

    we had to reduce to MTU size 1320 ON THE WORKSTATIONS in homeoffice behind a Unitymedia line.

    This works like a charm.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to PhilippRusch

    Thanks a lot I tested this with

    mssfix xxxx

    in the ovpn file and it seemed that large packets from LAN to VPN-Client got lost somewhere.

    How did you do that?

  • 0 in reply to LHerzog

    MTU-Size mit der Konsole setzen

    Das Setzen der MTU funktioniert auf der Konsole recht einfach.
    Zuerst listet man alle Netzwerkkarten auf:

    netsh interface ipv4 show interfaces

    Nun kann man den MTU-Wert durch Angabe der ID (Idx)

    netsh interface ipv4 set subinterface "11" mtu=1320 store=persistent

    oder der Bezeichnung (Name)

    netsh interface ipv4 set subinterface "LAN" mtu=1320 store=persistent

    neu einstellen. Die Einstellung „persistent“ behält dies auch nach einem Reboot bei.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to PhilippRusch

    thanks! will try that and report my findings

  • 0 in reply to LHerzog

    I have tested by setting the Client-Side-MTU 1320 only to the VPN Adapter, then only the LAN Adapter, then both Adapters simultaneously.

    Unfortunately I have not found any improvement abut the Office Files issue here the 6kb file from the Windows file server still takes 28-35 sec to open.
    Still don't have a clue about that issue here. Already disabled Sophos Endpoint Protection.

    I can copy a 10MB file from the very same Windows file server to the local client in 3 sec and a 512MB file in 110 seconds with MTU 1320. All quite good.

    And a copy of a 10MB file from the very same Windows file server to the local client in 3 sec and a 512MB file in 70 seconds with MTU 1500. Even better.

    Packetcapture during large file transfer with Client MTU 1320:

    Packetcapture during large file transfer with Client MTU 1500:

  • 0 in reply to LHerzog

    Hello,

    I forgot to mention, that the MTU of internal Interface of the router has to be 1320 bytes as well.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to PhilippRusch

    Did you try this app and beta drivers (selectable during installation)? In my case speed was much faster then Tap drivers^^

    openvpn.net/.../

    __________SETUP___________

    HP Small Form Factor:  i5 4Cores, 8Gb of RAM.
    Intel Network Card 5x Eth
    SSD: 256Gb

Unfiltered HTML