Share via

Azure VM configured with a fixed public IP address , no longer works

Lou Feliz 0 Reputation points
2026-03-12T05:05:09.3433333+00:00

Hello, I have an Azure VM that setup by our engineer on a vlan. The network had an Azure firewall. The particual machine was setup with a set public ip address so we could setup dns to allow inbound sftp etc... Outbound traffic was received by public service either as coming from firewall or the specific ip that routed traffic to the vm.

As of 2 days ago, I wake up to find that inbound traffic still comes in to the VM using the IP address configured for the host in DNS, but when request go outbound ,the public IP is now some other IP address owned my Microsoft (  xxxx) needless to say any outbound connections from this machine that needed the original IP (on host that have original IP in an ACL) are failing. I dont see how to rectify it as I did not change anything and my engineer swears he did not touch it either. IS Microsoft making changes somewhere and how do I find out what they are?

Azure Firewall
Azure Firewall

An Azure network security service that is used to protect Azure Virtual Network resources.

0 comments No comments

2 answers

Sort by: Most helpful
  1. Vallepu Venkateswarlu 6,905 Reputation points Microsoft External Staff Moderator
    2026-03-12T10:36:37.4966667+00:00

    Hi @ Lou Feliz,

    Welcome to Microsoft Q&A Platform.

    It looks like your VM is still receiving inbound traffic on the assigned static public IP, but the outbound traffic is being SNATed to a different Microsoft-owned IP. This typically happens when egress traffic is routed through Azure Firewall or when relying on Azure’s default outbound connectivity, instead of using an explicit outbound configuration tied to the VM’s public IP.

    By design, Azure Firewall SNATs outbound connections to one of its own public IPs (or to the default Azure cluster IP) unless a specific NAT or outbound rule is configured.

    Here are a few things you can check:

    • Verify the VM’s NIC still has the static public IP attached: In the Azure portal: Go to VM → NetworkingNetwork interfaceIP configurations: Confirm that your intended Public IP address is still associated with the NIC.
    • Check the subnet’s outbound configuration: If the subnet does not have a NAT Gateway attached, Azure Firewall or Azure’s default outbound connectivity will perform SNAT. Go to: Virtual networks → Subnets → Select the subnet: Verify whether a NAT Gateway is attached.
    • Attach a NAT Gateway for predictable outbound IP: Create or use an existing NAT Gateway with your reserved public IP(s), and associate it with the VM’s subnet. All outbound traffic will then use that IP. Ref: https://docs.microsoft.com/azure/nat-gateway/nat-overview
    • Configure Azure Firewall SNAT to use your public IP: In Azure Firewall → Public IP configuration, ensure that your reserved public IP is used for SNAT. If multiple public IPs are configured, Azure Firewall may round-robin SNAT across them.

    Ref: https://docs.microsoft.com/azure/virtual-network/ip-services/configure-public-ip-firewall#advanced-configuration

    (Alternative) Use a Standard SKU Public IP on the VM NIC: When a Standard SKU public IP is attached directly to a NIC, Azure disables default outbound access and forces outbound traffic to use that IP.

    Ref: https://docs.microsoft.com/azure/virtual-network/public-ip-addresses

    Please210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

    0 comments No comments

  2. Q&A Assist
    2026-03-12T05:05:28.0366667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The behavior indicates that the VM’s outbound traffic is no longer using the original dedicated public IP, but instead is using Azure’s default outbound mechanism or another egress path (for example, via a different public IP on the firewall or via a NAT/default outbound IP). This happens when the VM or subnet loses the configuration that previously pinned outbound traffic to a specific public IP.

    From the provided information, the following Azure behaviors are relevant:

    1. A VM without an assigned public IP can still reach the internet, but Azure will use a non‑configurable, shared outbound IP that can change at any time. This is the “default outbound access IP.”
    2. The default outbound access IP is automatically disabled when:
      • A public IP address is assigned directly to the VM, or
      • The VM is placed in the backend pool of a Standard Load Balancer, or
      • A NAT Gateway is assigned to the subnet.
    3. If a public IP is removed from the VM, or the VM is moved behind a different outbound mechanism (for example, a NAT Gateway or a different firewall configuration), outbound traffic will start using a different public IP.

    Given that inbound traffic still reaches the VM using the original DNS‑mapped public IP, but outbound is now seen as coming from a Microsoft‑owned IP (4.155.2.210), the most likely causes are:

    • The VM’s original public IP resource was disassociated from the NIC or changed from static to dynamic and then released.
    • The VM or subnet routing was changed so that outbound traffic now goes through a different path (for example, via a NAT Gateway or via Azure’s default outbound IP instead of the firewall/public IP that was originally used).
    • The VM was stopped/deallocated and restarted while using a dynamic public IP, causing Azure to assign a new outbound IP.

    To restore the original behavior (or at least a stable, known outbound IP) the supported options are:

    1. Ensure the VM has a static public IP associated with its NIC
      • Create or confirm a Static public IP resource (Standard SKU is recommended; Basic SKU is being retired).
      • Associate that public IP with the VM’s NIC IP configuration.
      • Verify that the allocation method is Static, not Dynamic, so the IP does not change on stop/start.
      • Confirm NSG rules allow the required inbound ports (for SFTP, etc.).
    2. Or, ensure outbound traffic is forced through a specific egress component
      • If using Azure Firewall or a NAT Gateway for outbound, verify that:
        • The VM’s subnet has a user‑defined route sending 0.0.0.0/0 to the firewall (if that is the intended egress).
        • The firewall or NAT Gateway has the expected public IP(s) configured.
      • Remove any conflicting configuration that might cause Azure to fall back to the default outbound IP (for example, removing a NAT Gateway or re‑associating the correct one, or re‑associating the correct public IP to the firewall).
    3. Verify the public IP type and assignment
      • If the original public IP was Dynamic, it may have changed when the VM was stopped/deallocated. To avoid this, use a Static public IP.
      • Static public IPs are assigned at creation and remain until the resource is deleted.
    4. Check for recent changes
      • Review activity logs for changes to:
        • The VM’s NIC IP configuration
        • Public IP resources (dissociation, deletion, SKU changes)
        • Route tables, NAT Gateways, or firewall configuration
      • Any such change in the last two days is likely the cause of the outbound IP change.

    There is no indication in the provided material of a Microsoft‑initiated change that would silently reassign outbound IPs for a correctly configured static public IP or firewall/NAT setup. The change almost always results from:

    • Loss or modification of the VM’s static public IP association, or
    • A change in routing/egress configuration (firewall, NAT Gateway, or load balancer), causing Azure to use a different outbound IP or the default outbound access IP.

    To fix the ACL issues on external systems, re‑establish a dedicated, static outbound IP (via a static public IP on the VM, Azure Firewall, or NAT Gateway) and update external ACLs only after confirming the new IP is stable.


    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.