none
Local file sharing using Internet bandwidth for file transfer. RRS feed

  • Question

  • Hello so I have this situation regarding my windows 8.1 machine and how it connects to my Windows Server 2012 machine.

    I have my Windows server machine directly connected to the internet on one ethernet port and the other is on a 192.168.1.0 private network.  

    My windows 8.1 Machine is also on this private network(192.168.1.0) and whenever I attempt to take files from my Windows server machine using its Local ip address it begins a connection from the Windows Server 2012 machines WAN IP to the local even though the established connection happened via file sharing by direct network ip address. This connection uses up all the throughput from my router causing every machine on the network to experience lag online.

    I also have Windows 7 machines and this issue does not occur when taking files from the server machine as it does it through LAN.

    I don't understand how the Windows 8.1 machine can even know my Server 2012 machines IP address or why its deciding to do these file transfers over the internet rather then LAN. 

    Here's an example since its a very difficult issue to explain.

    I have a Private network (192.168.1.0) this network reaches the internet from WAN 1.1.1.2. 

    In this network I have machines Windows 8.1 (192.168.1.8) and Windows server 2012 (192.168.1.12)

    I have a Windows Server 2012 Machine which reaches the internet directly from WAN 1.1.1.3. This machine has another nic located on the private network as stated above(192.168.1.12).

    When I use explorer on the windows 8.1 and use netstat -s it shows a connection

    192.168.1.8 -> 192.168.1.12 on port 445

    When I take a file and copy it to my desktop and use Netstat -s it shows connections

    192.168.1.8 -> 192.168.1.12 on port 445 and

    192.168.1.8 -> 1.1.1.3 on Port 445. (This connection does not happen in Windows 7).

    Hopefully this makes it clearer.

    Thanks,

    Martin


    Tuesday, October 13, 2015 1:31 PM

Answers

  • Hi Bored Martin,

    It is an expected behavior.
    By default, Windows 7 will use SMB 2.0 to access the share while Windows 8.1 will use SMB3.0 to access the share. There is a new feature called "Multichannel" of SMB 3.0, it is the reason.
    Here is the link for reference:
    The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0
    http://blogs.technet.com/b/josebda/archive/2012/05/13/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx

    If you are interested in testing this, we could refer to the following link to disable the feature to have a check.
    On the SMB server side:
    Set-SmbServerConfiguration -EnableMultiChannel $false
    On the SMB client side:
    Set-SmbClientConfiguration -EnableMultiChannel $false

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.


    Thursday, October 15, 2015 6:25 AM
    Moderator

All replies

  • Hi Bored Martin,

    It is an expected behavior.
    By default, Windows 7 will use SMB 2.0 to access the share while Windows 8.1 will use SMB3.0 to access the share. There is a new feature called "Multichannel" of SMB 3.0, it is the reason.
    Here is the link for reference:
    The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0
    http://blogs.technet.com/b/josebda/archive/2012/05/13/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx

    If you are interested in testing this, we could refer to the following link to disable the feature to have a check.
    On the SMB server side:
    Set-SmbServerConfiguration -EnableMultiChannel $false
    On the SMB client side:
    Set-SmbClientConfiguration -EnableMultiChannel $false

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.


    Thursday, October 15, 2015 6:25 AM
    Moderator
  • This seemed to have fixed the issue.

    Thanks!

    Thursday, October 15, 2015 2:04 PM