Repository navigation
Create a technical document giving detailed steps on how to configure Packer to use private Azure vNet with public IP聽#503
Description
Community Note
- Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Please search the existing issues for relevant feature requests, and use the
reaction feature
(https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
to add upvotes to pre-existing requests.
Description
Create a technical document giving detailed steps on how to configure Packer to use private Azure vNet with public IP. Such a guide would have saved me many hours trying to address this problem:
Without other changes, Packer in Azure creates a vNet, NSG, and public IP address resources. The NSG is to open access to WinRM, but is otherwise default out-of-box rules. The Packer NSG does not block SMB outbound ports 445 and 137-139, which my security organization has determined is a risk, even though the resources might be short lived. What if for example, the build fails and fails to clean up the resources? We have a running VM that has ports exposed to the Internet. We need to block those and such an article like this proposal would be a big help.
Use Case(s)
Where we can pre-create an Azure vNet, then create an associated Azure Network Security group (NSG). We can then edit that NSG and an an SMB outbound deny rule for ports 445, and 137-139. Now Packer can use that, it can create its public IP, and everyone is happy.
Code examples
Potential configuration
variable "virtual_network_name" {
type = string
default = "Packer_TempBuild_vNet"
}
variable "virtual_network_subnet_name" {
type = string
default = "default"
}
variable "virtual_network_resource_group_name" {
type = string
default = "packer-temp-build"
}
virtual_network_name = var.virtual_network_name
virtual_network_resource_group_name = var.virtual_network_resource_group_name
virtual_network_subnet_name = var.virtual_network_subnet_name
private_virtual_network_with_public_ip = true
Activity
fajterini commentedon Jun 25, 2025
Hi, Just my view as someone who implement this last month, for me the documentation was clear. We use vnet only and traffic is controlled with Azure Firewall.
This use case don't have logic " use private Azure vNet with public IP" you should either use Azure vnet when you have your private network properly secured with FW or create image in disconnected subscription with use of public IP. To use both internal network and public IP just create possible security vulnerability ...
Also for this NSG suggestion " The Packer NSG does not block SMB outbound ports 445 and 137-139" imagine use case that in your configuration you have steps that are downloading some files from internal file share .... This will create issues for another users.
Or maybe you are talking about Inbound SMB connection from public IP ??
JenGoldstrich commentedon Jun 27, 2025
Hey @robsmi-msfte, that's unfortunate that you ran into those issues, I'm sorry it wasn't clear from our documentation, as @fajterini mentions this field is documented in our list of fields, however we could always consider adding a new document page, where do you think such a technical document would have been more findable for you?
Personally I think that a better fix here would be for plugin to have a default security posture that blocks SMB access to the build VM, and only allows access to the WinRM or SSH port, either the default for the expected connector or the pre-configured one set in the template's
ssh_portandwinrm_portfields. This means that instead of you having to find a specific technical doc you're thinking about to fix your issue, you never would have had the issue to begin with, and the build VM the Packer Azure plugin creates will be more secure for the vast majority of users who only connect to their build VM using the ssh/winrm ports.So that this works by default for you, and we expose a way for users to allow ingress from specific ports for users who are like @fajterini suggests, using internal file share, which would be a perfectly valid use case that we don't want to permanently restrict.
Can you let me know what you think about this plan @robsmi-msfte , and if you have any opinions on where these docs should live