Azure's outbound connectivity follows a strict hierarchy. If your VM has a public IP directly attached to its network interface, it will always use that IP for outbound connections, completely bypassing any load balancer outbound rules. This defeats the entire purpose of using explicit outbound connectivity through the load balancer.
In the last post, we covered routing all your outbound access via a load balancer - this post will cover inbound access through the same load balancer.
What You Need to Do
The solution is to remove the public IP from your VM and reconfigure access through the load balancer using inbound NAT rules.
Step 1: Review Your Current Setup
Before making any changes, record everything about your current configuration:
- Current public IP address (you'll need this for DNS updates)
- Services running on the VM and their ports
- DNS records pointing to this IP
- Firewall rules or NSG rules specific to this IP
- SSL certificates tied to this IP address
- Application configurations using this IP
Step 2: Remove the Public IP from Your VM
Navigate to Your Virtual Machine
- Azure Portal → Virtual machines
- Select your VM
Access the Network Interface
- Click "Networking" in the left menu
- Click on the network interface name (usually ends with
-nic)
Remove Public IP Association
- In the network interface blade, click "IP configurations"
- Click on the IP configuration (typically named
ipconfig1) - Under "Public IP address" dropdown, select "None"
- Click "Save"
Verify the Change
- Return to your VM's overview page
- The "Public IP address" field should now show "None"
- Warning: Your VM now has no inbound internet access until you configure the load balancer
Step 3: Choose What to Do with the Public IP
You have two options for the public IP that was just removed from your VM:
Option A: Keep and Reuse the Public IP (Recommended)
If you need to maintain the same IP address (for existing DNS records, firewall rules, etc.):
- Add to Load Balancer Frontend
- Navigate to your load balancer → Frontend IP configuration
- Click "+ Add"
- Name: Inbound-LoadBalancer
- IP version: IPv4
- IP type: IP address
- Public IP address: Select the public IP you removed from the VM
- Click "Add"
Advantage: No DNS changes required, same IP address continues working.
Option B: Delete and Create New Public IP
If you want a fresh start with a new IP address:
Delete the Old Public IP
- Go to Public IP addresses in the portal
- Find your old VM's public IP
- Click "Delete"
Create New Public IP for Load Balancer
- Navigate to your load balancer → Frontend IP configuration
- Click "+ Add"
- Name: Inbound-LoadBalancer
- IP version: IPv4
- IP type: IP address
- Public IP address: Create new
- Name: load-balancer.extrernalip
- SKU: Standard
- Assignment: Static
- Click "Add"
Important: You will need to update all DNS records to point to the new IP address.
Step 4: Add VM to Load Balancer Backend Pool
Now that your VM has no public IP, you can add it to a backend pool:
Navigate to Your Load Balancer
- Go to your existing load balancer (or create one first)
- Click "Backend pools" in the left menu
Add the VM to Backend Pool
- Click on your backend pool (or create one)
- Click "+ Add"
- Target type: Virtual machine
- Virtual machine: Select your VM
- Network IP configuration: Select your VM's private IP configuration
- Click "Add"
- Click "Save"
Step 5: Create Inbound Rules for Access
Now configure how traffic reaches your VM through the load balancer:
For HTTPS Web Traffic:
- Create Load Balancing Rule
- In load balancer, go to "Load balancing rules"
- Click "+ Add"
- Name: https-rule
- Frontend IP address: Select your frontend IP
- Frontend port: 443
- Backend port: 443
- Backend pool: Select your backend pool
- Health probe: Create new HTTPS probe on port 443
- Click "Add"
For Additional Ports Based on Your Requirements:
Create Additional NAT Rules For each additional service you need to access, create a NAT rule:
- Go to "Inbound NAT rules"
- Click "+ Add"
- Name: Give it a descriptive name based on the service
- Frontend IP address: Select your frontend IP
- Frontend port: Choose an available port (can be same as backend or different)
- Target virtual machine: Select your VM
- Backend port: The port your service runs on inside the VM
- Protocol: TCP or UDP as required
- Click "Add"
Security Note: Changing the public port (e.g., SSH from 22 to 2222) provides no real security protection. Port scanning can easily identify services regardless of the port used - it's like making your Wi-Fi SSID hidden.
Common examples:
- Management access: Frontend port 22 → Backend port 22 (SSH)
- Remote desktop: Frontend port 3389 → Backend port 3389 (RDP)
- Custom application: Frontend port 80 → Backend port 80 (HTTP)
- Database: Frontend port 1433 → Backend port 1433 (SQL)
- API service: Frontend port 9000 → Backend port 9000
Step 6: Configure Outbound Rules
Don't forget the original purpose - fixing outbound connectivity:
- Create Outbound Rule
- In load balancer, go to "Outbound rules"
- Click "+ Add"
- Name: outbound-connectivity
- Frontend IP address: Select your public IP
- Protocol: All
- Backend pool: Select your backend pool
- Click "Add"
Step 7: Update DNS Records
Critical: Update all DNS entries that pointed to your old VM IP:
Update A Records
- Change from old VM IP to load balancer public IP
- Important: If you're using custom ports, you may need CNAME records or SRV records
Update Application Configurations
- Any hardcoded IP addresses in applications
- Connection strings in databases
- API endpoint configurations
Consider Port Changes
- If you were using standard ports (80, 443), update to your new NAT rule ports
- Update firewall rules to allow the new ports
Step 8: Restart Your VM
Important: Stop and start (deallocate) your VM for the outbound connectivity changes to take effect:
Stop VM
- Go to your VM in the portal
- Click "Stop"
- Wait for "Stopped (deallocated)" status
Start VM
- Click "Start"
- Wait for VM to fully boot
What Changes vs. What Stays the Same
What Stays the Same
- Your VM's private IP address
- Internal network connectivity
- All applications running on the VM
- VM performance and specifications
What Changes
- Access method: Now through load balancer NAT rules instead of direct IP
- Ports: May need to use custom ports instead of standard ones
- Outbound IP: Now uses load balancer IP instead of Microsoft's hidden IP
- DNS: Records point to load balancer instead of VM
Troubleshooting Common Issues
Cannot Connect After Conversion
- Are NAT rules configured correctly?
- Are you using the new port numbers?
- Did you restart the VM after configuration?
Applications Not Working
- Do applications bind to specific IP addresses?
- Are connection strings updated?
- Are firewall rules allowing the new ports?
Outbound Connectivity Issues
- Is the outbound rule configured?
- Is the VM in the backend pool?
- Did you restart the VM after outbound rule creation?
Conclusion
Converting a VM from having a direct public IP to being part of a load balancer backend pool requires careful planning and execution, but it provides better security, more predictable outbound connectivity, and solves the Azure default outbound access security.