HTTPIP on Windows gets IP address from wrong Ethernet adapter

[Weilbyte]

Overview of the Issue

When using Packer on Windows, the {{ .HTTPIP }} variable picks up the wrong IP address. My ipconfig looks like this below:

Windows IP Configuration


Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::4db:cb2a:a777:7cd2%26
   IPv4 Address. . . . . . . . . . . : 172.25.16.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::20b0:da9b:6cb1:e6b%32
   IPv4 Address. . . . . . . . . . . : 172.18.96.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : localdomain
   IPv4 Address. . . . . . . . . . . : 10.0.30.44
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.30.1

The last adapter, Ethernet is the one that should be picked as that is the only one accessible by my local server where the VM is provisioned. However Packer insists on using 172.25.16.1 for HTTPIP. This can probably be avoided by specifying bind address to the correct one, but then this configuration becomes specific to the machine it runs on as the bind address would need to be changed.

Reproduction Steps

1. Have some vEthernet adapters, usually from a WSL/WSL2 installation.
2. Use the HTTPIP variable.
3. The HTTPIP variable is the IP address of the vEthernet adapters.

Packer version

Packer v1.6.4

Simplified Packer Buildfile

Shouldn't be buildfile specific.

{
      "boot_command": [
        "<enter><enter><f6><esc><wait> ",
        "autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/",
        "<enter>"
      ],
}

Operating system and Environment details

Running from Windows 10 machine.
Using Proxmox builder.

[nywilken]

Hi @Weilbyte thanks for reaching out. The HTTP server IP detection will default to the first non-loopback interface. Unfortunately selecting the correct interface is not something Packer can do without a little help. There is a configuration option called http_interface which allows you to select which interface Packer should use for the HTTP server.

Have you tired setting http_interface?

I understand how that makes the configuration a bit host specific so I would recommend using a variable for setting the interface. If you don't set a default value the build will require the user to set it at run time to the appropriate value.

With that said, the HTTP server is actually bond to 0.0.0.0 so if you provide the configuration the correct address back to the machine running the build it should be able to access the server. This means that instead of using {{ .HTTPIP}} you would hard code the IP. This is a workaround. I think the correct path forward would be to use the http_interface attribute in your build template.

I don't think this is a bug so I am going to add the question label to this issue for now. But if you think differently or run into problems with the suggested solutions please don't hesitate to let us know. Cheers!

[Weilbyte]

Thanks @nywilken for responding. A variable for http_interface would indeed do the job so I will use that for now. But for the future, perhaps it should prioritize interfaces that have internet access?

[nywilken]

Glad to hear the http_interface attribute was able to get you moving.

But for the future, perhaps it should prioritize interfaces that have internet access?

Regarding your question, I don't think that this is something that Packer would be able to guarantee to be correct even with added logic for testing connectivity to and from the guest host, Internet, etc. With that said, I can see a case where Packer is working in entirely closed network where Internet is not available. In these cases our approach is to let the user tell Packer what the right path is to avoid any issues.

I'm going to close this issue since I don't think there is anything for us to do here. But if you or another member of the Packer community is interested in opening up a PR that improves on interface/Ethernet detection we would be happy to review and take it into consideration. Cheers 😄

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.