Winsock SO_EXCLUSIVEADDRUSE on Vista

I've been asked a couple times about the socket option SO_EXCLUSIVEADDRUSE on Vista and especially how it relates to dual stack sockets. The following doc link describes the basic idea of this socket option:

https://msdn2.microsoft.com/en-us/library/ms740621.aspx

However, it hasn't been updated with any Vista specific behavior. We're working on updating that doc but it takes a while for the change to propagate to the web.

Vista follows the same rules as Windows Server 2003 when looking at that documentation, but what happens when using a dual stack socket? A dual stack socket is one that is created as IPv6 but then the IPV6_V6ONLY socket option is set to false. This results in the socket being bound to the same port on both the IPv4 and IPv6 stack. This mans that the security check is performed for the given port on both the IPv4 and IPv6 networking stacks. If either check fails, the entire bind request fails.

For example, a IPv6 dual stack socket is to be bound to port 5150 on the wildcard address (since it doesn't make sense to bind a dual stack socket to a specfic IP address). If SO_EXCLUSIVEADDRUSE is not set, then the bind will succeed even if there is another socket (IPv4 or IPv6) bound to a specific IP address on port 5150. This is no different what is described in the article above. However, if SO_EXCLUSIVEADDRUSE was set then if any other socket is bound to port 5150 (either IPv4 or IPv6), the bind call will fail thus indicating that you don't have exclusive access to that port.

Just as a reminder, applications should never set SO_REUSEADDR except for some very specific uses (e.g. multicasting) while servers should always set SO_EXCLUSIVEADDRUSE.

--Anthony Jones (AJones)

Comments

• Anonymous
  December 20, 2007
  On behalf of Windows Vista customers who rely on SSH for SMB forwarding: I humbly request if you can forward this to someone who can meaningfully respond to this inquiry. Thank you! Dear Microsoft, for several years, users like us have been relying on an ability to tunnel Windows file shares over the SSH protocol to enable Windows file sharing to work securely across the internet without requiring complex VPN solutions to be set up. The way the SSH tunneling approach works is that a program running on the Windows machine that is the sharing consumer listens on port 139 or port 445, and forwards any connection requests across SSH to port 139 or 445 on the server. The user then establishes a file sharing connection to the server by navigating to \127.0.0.1ShareName. Alternately, the user sets up the SSH client to accept connections on an interface configured using the Microsoft Loopback Adapter, say 10.10.10.10, and then navigating to \10.10.10.10ShareName. The critical characteristic that has made this solution possible, until now, is that there was always some way to convince Windows to connect to the SSH client, instead of Windows connecting to the same SMB port it is listening on, itself. Unfortunately, recent changes you have made in Vista updates seem to leave us with no more ways to convince Windows to connect to the SSH client, instead of connecting to itself. If the SSH client listens on port 139, then Windows will not try to connect to that port because it tries connecting to port 445 instead, and so it connects to itself. On the other hand, recent Windows security updates have made it impossible for the SSH client to listen on port 445 - even if on an interface assigned to a Microsoft Loopback Adapter installed for that purpose. Can you provide us with instructions for a reliable way to configure Vista so that navigating to a certain share will result in a connection to the SSH client, and not to Windows itself? Can you provide us with instructions to do so in a way that does not require us to completely uninstall File and Printer Sharing? If this is not possible using Windows Vista with all the most recent updates, would you consider reopening the possibility in a future update? Thank you and best regards, denis bider Bitvise See topics: 10013 error when forwarding port 445 https://fogbugz.bitvise.com/default.asp?Tunnelier.2.8400 Vista patch breaks forwarding of port 445? http://fixunix.com/ssh/263661-vista-patch-breaks-forwarding-port-445-a.html