Unusually large dynamicport range is configured for the GitHub Actions windows-latest machine

[ben-spiller]

Does anyone know why/if if it’s deliberate that the GitHub Actions “os: windows-latest” machine (non-docker) has an unusual configuration for the TCP dynamic (=ephemeral) port range?

As far as I know from the Microsoft docs all recent Windows versions are configured to follow the IANA standard port range for ephemeral ports, which gives plenty of ports for both ephemeral and server:

netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
Start Port : 49152
Number of Ports : 16384

However on the GitHub Actions Windows machine it’s got a slightly mad (? 🙃 ) configuration which assigns 100% of the ports to ephemeral use and leaves none for starting servers:

netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
Start Port : 1024
Number of Ports : 64511

I couldn’t see anything in the doc about this, so was assuming Actions would be providing a fairly standard configuration. Is it intended or a bug? Would certainly be good to document if this machine has an unusual configuration.

I’m using GitHub Actions for a testing framework that needs to allocate lots of server ports to run tests of a server application, and our algorithm for allocating ports (excluding the ephemeral range) falls over with this configuration. I can use “netsh int ipv4 set dynamicportrange tcp” as a workaround but would like to understand if this atypical machine configuration was intended, and if so it’d be great to mention this (and any other unusual configuration choices) in the docuemntation.

[weide-zhou]

Hi @ben-spiller,

Thank you for reaching this out!

GitHub hosts Linux and Windows runners on Standard_DS2_v2 virtual machines in Microsoft Azure (doc here). The configuration including port is consistent.

checked on Github:

image751×255 9.21 KB

Checked with Azure ‘windows-2019’ machine:

image881×229 13.8 KB

Thanks

[ben-spiller]

Thanks for looking into this!

I just created a win2019 machine myself in azure (“Windows Server 2019 Datacenter”)
and it’s using the standard IANA range:

Protocol tcp Dynamic Port Range

Start Port : 49152
Number of Ports : 16384

The MS docs for dynamicport are a bit sketchy but https://support.microsoft.com/en-gb/help/929851/the-default-dynamic-port-range-for-tcp-ip-has-changed-in-windows-vista seems to indicate the same IANA port range (dynamicport for 19152+) for modern windows versions (see the “applies to” which includes 2019).

I wonder why you’re seeing something different. How exactly did you create your win2019 Azure machine where you saw the 1024+ dynamic port range? Did you tick any non-default options? I did: “create a virtual machine”, selected my region (UK South), image=2019 gen1, size=DS1_v2 (DS2 option was not available), inbound port rules=allow selected (RDP i.e. the default). But I doubt any of those would make a difference to this.

I don’t suppose anyone reading this knows someone in the Azure or Windows Server teams who might be able to shed light on why some machines seem to have a different out-of-the-box dynamicport configuration?

[weide-zhou]

Hi @ben-spiller,

Thanks for your reply!

No special setting on my azure pipeline, just select windows-2019 and use a powershell script to get the info, this will use hosted vm for checking. (didn’t create VM)

image983×388 13.9 KB

Powershell script:

netsh int ipv4 show dynamicport tcp
echo ------------------
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Could you please check on your side?

Thanks

[al-cheb]

Hi, @ben-spiller
We generate images for GitHub and Azure Pipelines using the https://github.com/actions/virtual-environments repository.

After installing VS via script https://github.com/actions/virtual-environments/blob/2602d388778a3626a5cba3f332bbf4283b4a5fa2/images/win/scripts/Installers/Install-VS.ps1 the dynamic port range is changed to:

Protocol tcp Dynamic Port Range
    vhd: ---------------------------------
    vhd: Start Port      : 1024
    vhd: Number of Ports : 64511

Example https://github.visualstudio.com/virtual-environments/_build/results?buildId=78654&view=logs&j=011e1ec8-6569-5e69-4f06-baf193d1351e&t=486c0909-f67d-5748-80b3-bb1d531e7b43 :

Before Visual Studio installation [703]:

==> vhd: Provisioning with powershell script: C:\agent\_work\9\s\images\win/scripts/Installers/Install-VS.ps1
    vhd: Display ports
    vhd:
    vhd: Protocol tcp Dynamic Port Range
    vhd: ---------------------------------
    vhd: Start Port      : 49152
    vhd: Number of Ports : 16384

After [825]:

    vhd: Display ports
    vhd:
    vhd: Protocol tcp Dynamic Port Range
    vhd: ---------------------------------
    vhd: Start Port      : 1024
    vhd: Number of Ports : 64511
    vhd:

We are currently discussing to revert ports to the default values or update the documentation (https://github.com/actions/virtual-environments/blob/2602d388778a3626a5cba3f332bbf4283b4a5fa2/images/win/Windows2019-Readme.md) about that moment.

[ben-spiller]

Great thanks for doing that analysis!

Wow this is quite surprising that installating Visual Studio 2019 seems to have changed the machine’s dynamicport TCP configuration. I couldn’t find any VS documentation about that, it smells like possibly an unintentional change/bug?

Either way I guess the https://github.com/actions/virtual-environments/blob/9110b389998666dc0c6a8e9abd9400248bad8dba/images/win/scripts/Installers/Install-VS.ps1 could perhaps revert back to the default Windows configuration to avoid surprising people with this more limited TCP configuration that’s not good for server processes.

Anyway thanks for looking into it, I look forward to hearing what you come up with :slight_smile:

[al-cheb]

@ben-spiller, I have prepared the actions/runner-images#1442 PR to revert the default value.

[al-cheb]

@ben-spiller, The image with dynamic port changes has been deployed.

image893×672 23 KB

[ben-spiller]

Awesome thanks, I’ve removed my workaround and now it’s working as expected. Thanks for the quick turnaround :slight_smile:

[ben-spiller]

Seems quite dodgy that Visual Studio is changing the machine’s TCP config in this radical way (without any documentation I’m aware of to let user’s know) but I guess that’s a problem for someone else to solve