The Deploy.ps1 script gets a IPV6 Public IP instead of and IPV4, causing an error while setting up the SQL firewall rule

[Giancarl021]

Describe the bug When running the Deploy.ps1 file, I get an FirewallRuleNotIPv4Address, showing that the service ifconfig.me is returning the wrong IP type.

To Reproduce Steps to reproduce the behavior:

1. Execute the Deploy.ps1 PowerShell file;
2. On the line 350, it will grab the IPV6 IP address, instead of the expected IPV4;
3. An FirewallRuleNotIPv4Address error will be thrown

Expected behavior The correct IP type to be returned by the ifconfig.me service, which will lead to a clean execution.

Screenshots

      ➡️ Add SQL Server Firewall rules
{
  "endIpAddress": "0.0.0.0",
  "id": "/subscriptions/***/resourceGroups/SaaS-Accelerator/providers/Microsoft.Sql/servers/***/firewallRules/AllowAzureIP",
  "name": "AllowAzureIP",
  "resourceGroup": "***",
  "startIpAddress": "0.0.0.0",
  "type": "Microsoft.Sql/servers/firewallRules"
}
      ➡️ Running in local environment - Add current IP to firewall
(FirewallRuleNotIPv4Address) '0000:0000:0000:0000:0000:0000:0000:0000' is not a valid IPv4 address.
Code: FirewallRuleNotIPv4Address
Message: '0000:0000:0000:0000:0000:0000:0000:0000' is not a valid IPv4 address.

Environment (please complete the following information):

• Are you using the CloudShell? No
• If not using the CloudShell:
  • OS: Ubuntu 22.04.3 LTS
  • PowerShell version: 7.4.0
  • Modules installed:
    • Az
    • Az.Accounts
    • Az.Advisor
    • Az.Aks
    • Az.AnalysisServices
    • Az.ApiManagement
    • Az.App
    • Az.AppConfiguration
    • Az.ApplicationInsights
    • Az.ArcResourceBridge
    • Az.Attestation
    • Az.Automanage
    • Az.Automation
    • Az.Batch
    • Az.Billing
    • Az.Cdn
    • Az.CloudService
    • Az.CognitiveServices
    • Az.Compute
    • Az.ConfidentialLedger
    • Az.ContainerInstance
    • Az.ContainerRegistry
    • Az.CosmosDB
    • Az.DataBoxEdge
    • Az.Databricks
    • Az.DataFactory
    • Az.DataLakeAnalytics
    • Az.DataLakeStore
    • Az.DataProtection
    • Az.DataShare
    • Az.DeploymentManager
    • Az.DesktopVirtualization
    • Az.DevCenter
    • Az.DevTestLabs
    • Az.Dns
    • Az.EventGrid
    • Az.EventHub
    • Az.FrontDoor
    • Az.Functions
    • Az.HDInsight
    • Az.HealthcareApis
    • Az.IotHub
    • Az.KeyVault
    • Az.Kusto
    • Az.LoadTesting
    • Az.LogicApp
    • Az.MachineLearning
    • Az.MachineLearningServices
    • Az.Maintenance
    • Az.ManagedServiceIdentity
    • Az.ManagedServices
    • Az.MarketplaceOrdering
    • Az.Media
    • Az.Migrate
    • Az.Monitor
    • Az.MySql
    • Az.Network
    • Az.NetworkCloud
    • Az.NotificationHubs
    • Az.OperationalInsights
    • Az.PolicyInsights
    • Az.PostgreSql
    • Az.PowerBIEmbedded
    • Az.PrivateDns
    • Az.RecoveryServices
    • Az.RedisCache
    • Az.RedisEnterpriseCache
    • Az.Relay
    • Az.ResourceMover
    • Az.Resources
    • Az.Security
    • Az.SecurityInsights
    • Az.ServiceBus
    • Az.ServiceFabric
    • Az.SignalR
    • Az.Sql
    • Az.SqlVirtualMachine
    • Az.StackHCI
    • Az.Storage
    • Az.StorageMover
    • Az.StorageSync
    • Az.StreamAnalytics
    • Az.Support
    • Az.Synapse
    • Az.TrafficManager
    • Az.Websites
    • SqlServer
    • Microsoft.PowerShell.Archive
    • Microsoft.PowerShell.Host
    • Microsoft.PowerShell.Management
    • Microsoft.PowerShell.PSResourceGet
    • Microsoft.PowerShell.Security
    • Microsoft.PowerShell.Utility
    • PackageManagement
    • PowerShellGet
    • PSReadLine
    • ThreadJob

Additional context

• Maybe this problem arises only on specific machines or User-Agents, I'm not sure;
• A potential solution would be to simply change the Public IP service, such as ipify (which got my correct IPV4 address).