SMBv2-v3 on Mobile Access File Share (and not only SMBv1 - CIFS)

[XBensemhoun]

Hi,

I've found some unclear information regarding Server_Message_Block versions supported on mobile-access-blade file-share functionality.

What is unclear? We have "A file share defines a collection of files (...) such as SMB for Windows" in the MobileAccess Admin Guide R77 or in the sk104577 ATRG: Mobile Access Blade .

Even the sk111097 Slow upload speed of files via Mobile Access File Share (CIFS for example) says "CIFS for example".

BUT referring the sk112202 File Shares using SMBv2/SMBv3 cannot be accessed using the Mobile Access Blade File Share applicatio... : Mobile Access only support SMBv1 (formerly CIFS) and not SMBv2 nor SMBv3 (on any version and any platform).

Even in the ATRG, we have the picture bellow:

So, could we:

• Be more accurate and say that only SMBv1 (CIFS) is supported on Mobile Access File Share functionality
• support SMBv2 or SMBv3 ?

I've asked yesterday ‌ team to understand if there is a plan to support such versions.

[PhoneBoy]

The reason we don't currently support SMBv2/v3 has to do with the Linux kernel we are using.

Once the gateway supports a newer kernel (like is planned for R80.20), it should be possible to support SMBv2/v3. 

However, I can't say if R80.20 will support this out of the gate. 

[XBensemhoun]

And secureknowledge‌ team answered:

R&D responded: "It's a known RFE."
sk was modified accordingly.

The Solution part of the sk112202‌ as been effectively updated:

So: do not hesitate to Request for Enhancement.

[Jeroen_Demets]

Ouch, I'm disappointed as SMB1 should be gone everywhere... too many vulnerabilities in it (remember wannacry?)

Check this link, even Microsoft wants it to be obsolete: https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/ 

I'll submet the RFE right now as only supporting SMB1 is not worthy for a security vendor!

[Timothy_Hall]

Not to pile on here, but SMBv1 does not handle latency in excess of what is typically encountered on a LAN very well.  Quoted from the second edition of my book:

Special Case: CIFS/SMB Performance over VPN

The well-known CIFS/SMB (Common Internet File System/Server Message Block)
protocol frequently experiences degraded performance in the context of a site-to-site or
Remote Access VPN, but probably not for the reason you think. Commonly used for
mounting drive shares (among other functions) in Microsoft Windows networks,
CIFS/SMB version 1 was originally intended and optimized for use in a low-latency
LAN environment. Part of this optimization was the requirement that for every certain
amount of data sent (called an Application Block Size which ranges between 4KBytes-
64Kbytes), an acknowledgement must be received from the peer before any more data
can be sent. Note that this peer acknowledgement requirement is part of CIFS/SMB
itself, and completely unrelated to the underlying transport protocol such as TCP window
sizes or ACKs. The Network File System (NFS) protocol was also originally designed to
run across a LAN with assumed low latency.

While this performance limitation of CIFS/SMB version 1 is not directly related to
the use of a VPN, the networks employed by a VPN such as the Internet tend to have
significantly higher latency than LAN or private WAN connections. There could be an
impressive 10Gbit of Internet bandwidth between two sites on the Internet, but if the
latency is 100ms or greater, CIFS performance across the VPN (or even in the clear) will
be dismal no matter what you do.

While there is really no firewall tuning we can perform to improve this situation,
there is something you can do: Try to force the systems involved to utilize SMB version
2.1 or higher which supports pipelining; many very old Windows systems still default to
SMBv1. While the peer acknowledgement requirement still exists in SMB version 2.1
and later, pipelining allows multiple Application Blocks to be in transit between the
peers simultaneously instead of just one block at a time. Ensuring the use of SMB
version 2.1 or higher can provide dramatic CIFS/SMB performance improvements across
a VPN or any other network with high latency.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Jeroen_Demets]

old topic, but just wanted to reply that Gaia on kernel 3.10 gateways support SMBv2/v3

So that is one reason to reinstall your gateways instead of upgrading so you can use the new kernel

[Dreyfuss]

So, there a way to force "SMBv3 only" on the Gaia?

[PhoneBoy · Accepted solution]

You can force it on the server side, I think, which is the correct approach.
In any case, we only support SMBv2/v3 on releases with Linux 3.10 kernel (default in R80.40).

[Dreyfuss]

Thank you.

[Dreyfuss]

Hi! The default for 80.30 is SMBv1, not v2/3. You must enforce the SMBv2/3 on Gaia side.