Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 41 subscribers
  • Views 10880 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 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

    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

    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?

Unfiltered HTML