Azure 防火牆的已知問題和限制
本文列出 Azure 防火牆的已知問題。 問題解決時會加以更新。
針對 Azure 防火牆限制,請參閱 Azure 訂用帳戶和服務限制、配額與限制。
Azure 防火牆標準
Azure 防火牆標準版有下列已知問題:
注意
適用於標準版的任何問題也適用於進階版。
問題 | 描述 | 風險降低 |
---|---|---|
限於標準和進階版本的私人 IP 位址 DNAT 支援 | Azure 防火牆私人 IP 位址上的 DNAT 支援預定用於企業,因此受限於標準和進階防火牆版本。 | 無 |
非 TCP/UDP 通訊協定 (例如 ICMP) 的網路篩選規則,不適用於流向網際網路的流量 | 非 TCP/UDP 通訊協定的網路篩選規則,無法與 SNAT 搭配用於您的公用 IP 位址。 在輪輻子網路與 VNet 之間支援非 TCP/UDP 通訊協定。 | Azure 防火牆會使用 Standard Load Balancer,目前針對 IP 通訊協定不支援 SNAT。 我們正在探索選項,以在未來的版本中支援這種案例。 |
對於 ICMP 缺少 PowerShell 和 CLI 支援 | Azure PowerShell 和 CLI 不支援在網路規則中將 ICMP 作為有效的通訊協定。 | 您仍可透過入口網站和 REST API 來使用 ICMP 作為通訊協定。 我們正努力盡快在 PowerShell 和 CLI 中新增 ICMP。 |
FQDN 標籤需要設定「通訊協定:連接埠」 | 具有 FQDN 標籤的應用程式規則需要「連接埠: 通訊協定」定義。 | 您可以使用 https 作為「連接埠:通訊協定」值。 我們正努力讓此欄位在使用 FQDN 標籤時可作為選擇性欄位。 |
不支援將防火牆移動到不同的資源群組或訂用帳戶 | 不支援將防火牆移動到不同的資源群組或訂用帳戶。 | 在我們的規劃中,未來會支援這項功能。 若要將防火牆移動到不同的資源群組或訂用帳戶,您必須刪除目前的執行個體,並將其重新建立在新的資源群組或訂用帳戶中。 |
威脅情報警示可能會遮罩處理 | 目的地為 80/443 的網路規則,可供輸出篩選遮罩處理設定為僅限警示模式的威脅情報警示。 | 使用應用程式規則建立 80/443 的輸出篩選。 或者,將威脅情報模式變更為 [警示並拒絕]。 |
使用安全的虛擬中樞,可用性區域只能在部署期間進行設定。 | 在部署具有安全虛擬中樞的防火牆之後,您無法設定可用性區域。 | 這是原廠設定。 |
輸入連線上的 SNAT | 除了 DNAT,透過防火牆公用 IP 位址 (輸入) 的連線已對其中一個防火牆私人 IP 進行 SNAT 轉譯。 這項需求現在也適用於主動/主動 NVA 以確保對稱式路由。 | 若要保留 HTTP/S 的原始來源,請考慮使用 XFF 標題。 例如,在防火牆前使用 Azure Front Door 或 Azure 應用程式閘道等服務。 您也可以將 WAF 新增為 Azure Front Door 的一部分和防火牆鏈結。 |
SQL FQDN 篩選支援僅限於 Proxy 模式 (連接埠 1433) | 針對 Azure SQL Database、Azure Synapse Analytics 和 Azure SQL 受控執行個體: 只有 Proxy 模式才支援 SQL FQDN 篩選 (連接埠 1433)。 針對 Azure SQL IaaS: 如果您使用非標準連接埠,您可以在應用程式規則中指定這些連接埠。 |
在重新導向模式中使用 SQL 時 (這是從 Azure 內連線時的預設值),您可以改為使用 SQL 服務標籤作為 Azure 防火牆網路規則的一部分來篩選存取。 |
TCP 通訊埠 25 上的輸出 SMTP 流量會遭到封鎖 | Azure 平台會封鎖 TCP 通訊埠 25 上直接傳送至外部網域的輸出電子郵件訊息,例如 outlook.com 和 gmail.com 。 這是 Azure 中的預設平台行為。 Azure 防火牆不會引入任何更具體的限制。 |
請使用已驗證的 SMTP 轉送服務,這類服務通常會透過 TCP 通訊埠 587 連線,但也支援其他連接埠。 如需詳細資訊,請參閱針對 Azure 中的輸出 SMTP 連線能力問題進行疑難排解。 另一個選項是在標準 Enterprise 合約 (EA) 訂用帳戶中部署 Azure 防火牆。 EA 訂用帳戶中的 Azure 防火牆可以使用輸出 TCP 連接埠 25 與公用 IP 位址通訊。 目前,也可以在其他訂用帳戶類型中運作,但不保證可以運作。 對於虛擬網路、VPN 和 Azure ExpressRoute 等私人 IP 位址,Azure 防火牆支援 TCP 通訊埠 25 上的輸出連線。 |
SNAT 連接埠耗盡 | Azure 防火牆目前針對每個後端虛擬機器擴展集執行個體的每個公用 IP 位址,支援 2,496 個連接埠。 根據預設,一共會有兩個虛擬機器擴展集執行個體。 因此,每個流程 (目的地 IP、目的地埠和通訊協定 (TCP 或 UDP)) 有 4,992 個連接埠。 防火牆最多可擴大至 20 個執行個體。 | 這是平台限制。 針對易受到 SNAT 耗盡影響的部署,您可以為 Azure 防火牆部署至少設定五個公用 IP 位址以緩解限制。 這會使可用的 SNAT 連接埠增加五倍。 配置 IP 位址前置詞以簡化下游權限。 如需更長久的解決方案,您可以部署 NAT 閘道來克服 SNAT 連接埠限制。 虛擬網路部署支援此方法。 如需詳細資訊,請參閱使用 Azure 虛擬網路 NAT 調整 SNAT 連接埠的規模。 |
啟用強制通道時不支援 DNAT | 因為非對稱式路由,部署了強制通道的防火牆無法支援來自網際網路的輸入存取。 | 這是因為非對稱式路由的設計。 輸入連線的傳回路徑會透過內部部署防火牆進行,而此防火牆並未顯示已建立的連線。 |
視您的 FTP 伺服器設定而定,輸出被動 FTP 可能不適用於具有多個公用 IP 位址的防火牆。 | 被動 FTP 會針對控制和資料通道建立不同的連線。 當具有多個公用 IP 位址的防火牆傳送輸出資料時,會為來源 IP 位址隨機選取其中一個公用 IP 位址。 視您的 FTP 伺服器設定而定,當資料和控制通道使用不同的來源 IP 位址時,FTP 可能會失敗。 | 已規劃了明確的 SNAT 組態。 在此同時,您可以將 FTP 伺服器設定為接受來自不同來源 IP 位址的資料和控制通道 (請參閱 IIS 的範例)。 或者也可以考慮使用單一 IP 位址。 |
視您的 FTP 伺服器設定而定,可能無法使用輸入被動 FTP | 被動 FTP 會針對控制和資料通道建立不同的連線。 Azure 防火牆上的輸入連線會透過 SNA 轉譯到其中一個防火牆私人 IP 位址,以確保路由對稱。 視您的 FTP 伺服器設定而定,當資料和控制通道使用不同的來源 IP 位址時,FTP 可能會失敗。 | 保留正在調查的原始來源 IP 位址。 在此同時,您可以將 FTP 伺服器設定為接受來自不同來源 IP 位址的資料和控制通道。 |
當 FTP 用戶端必須透過網際網路連線到 FTP 伺服器時,主動 FTP 無法運作。 | 作用中 FTP 會利用 FTP 用戶端的 PORT 命令,將 FTP 伺服器導向要用於資料通道的 IP 和連接埠。 此 PORT 命令會利用無法變更的用戶端私人 IP。 往返 Azure 防火牆的用戶端流量將會是網際網路型通訊的 NAT,因此 FTP 伺服器會將 PORT 命令視為無效。 | 這是搭配用戶端 NAT 使用時,主動 FTP 的一般限制。 |
NetworkRuleHit 計量缺少通訊協定維度 | ApplicationRuleHit 計量允許篩選型的通訊協定,但對應的 NetworkRuleHit 計量中缺少這項功能。 | 我們正在調查提供修正程式的可能性。 |
不支援在 64000 與 65535 之間使用連接埠的 NAT 規則 | Azure 防火牆允許網路和應用程式規則使用 1-65535 範圍中的任何連接埠,不過 NAT 規則只支援 1-63999 範圍中的連接埠。 | 這是目前的限制。 |
組態更新平均可能需要 5 分鐘 | Azure 防火牆組態更新平均可能需要三到五分鐘,而且不支援平行更新。 | 我們正在調查提供修正程式的可能性。 |
Azure 防火牆會使用 SNI TLS 標頭來篩選 HTTPS 和 MSSQL 流量 | 如果瀏覽器或伺服器軟體不支援伺服器名稱指示 (SNI) 擴充,您就無法透過 Azure 防火牆連線。 | 如果瀏覽器或伺服器軟體不支援 SNI,您或許能夠使用網路規則 (而非應用程式規則) 來控制連線。 如需可支援 SNI 的軟體,請參閱伺服器名稱指示。 |
無法使用入口網站或 Azure Resource Manager (ARM) 範本新增防火牆原則標籤 | Azure 防火牆原則具有修補支援限制,將會防止您使用 Azure 入口網站或 ARM 範本新增標籤。 系統會產生下列錯誤:無法儲存資源的標籤。 | 我們正在調查提供修正程式的可能性。 或者,您可以使用 Azure PowerShell Cmdlet Set-AzFirewallPolicy 來更新標籤。 |
目前不支援 IPv6 | 如果您將 IPv6 位址新增至規則,防火牆將會失敗。 | 只可使用 IPv4 位址。 未來將支援 IPv6。 |
更新多個 IP 群組由於衝突錯誤而失敗。 | 當您更新連結至相同防火牆的兩個或多個 IP 群組時,其中一個資源會進入失敗狀態。 | 這是已知的問題/限制。 當您更新 IP 群組時,系統會在 IPGroup 所連結的所有防火牆上觸發更新。 如果第二個 IP 群組的更新啟動時,防火牆仍處於 Updating (正在更新) 狀態時,則 IPGroup 更新會失敗。 若要避免失敗,針對附加至相同防火牆的 IP 群組,請務必一次更新一個。 在更新之間請保留足夠的時間,讓防火牆結束 Updating (正在更新) 狀態。 |
不支援移除使用 ARM 範本的 RuleCollectionGroups。 | 不支援移除使用 ARM 範本的 RuleCollectionGroup,而且會導致失敗。 | 這不是支援的作業。 |
允許「所有」(*) 的 DNAT 規則一律為 SNAT 流量。 | 如果 DNAT 規則允許任何 (*) 作為來源 IP 位址,則隱含網路規則會比對 VNet-VNet 流量,且流量一律採用 SNAT。 | 這是目前的限制。 |
不支援將 DNAT 規則新增至具有安全性提供者的安全虛擬中樞。 | 這會導致傳回 DNAT 流量的非同步路由,而該流量會傳送至安全性提供者。 | 不支援。 |
建立超過 2,000 個規則集合時發生錯誤。 | NAT/應用程式或網路規則集合的數量上限為 2000 個 (Resource Manager 限制)。 | 這是目前的限制。 |
HTTP/S 中的 XFF 標頭 | XFF 標頭覆寫為防火牆所見的原始來源 IP 位址。 這適用於下列使用案例: - HTTP 要求 - 具有 TLS 終止的 HTTPS 要求 |
我們正在調查提供修正程式的可能性。 |
無法使用新建立的公用 IP 位址部署具有 Azure 可用性區域的防火牆 | 在部署具有 Azure 可用性區域的防火牆時,您無法使用新建立的公用 IP 位址。 | 請先建立新的區域備援公用 IP 位址,然後在防火牆部署期間指派先前建立的 IP 位址。 |
日本東部的實體區域 2 無法用於防火牆部署。 | 您無法使用實體區域 2 部署新防火牆。 此外,如果您停止部署在實體區域 2 的現有防火牆,則無法重新啟動。 如需詳細資訊,請參閱實體和邏輯可用性區域。 | 針對新的防火牆,請使用剩餘的可用性區域進行部署,或使用不同的區域。 若要設定現有的防火牆,請參閱如何在部署後設定可用性區域?。 |
Azure 防火牆進階
Azure 防火牆進階版有下列已知問題:
問題 | 描述 | 風險降低 |
---|---|---|
HTTPS 中 FQDN 解析的 ESNI 支援 | HTTPS 交握不支援加密的 SNI。 | 目前只有 Firefox 透過自訂設定支援 ESNI。 建議的因應措施是停用此功能。 |
不支援用戶端認證驗證 | 用戶端憑證可用來組建用戶端與伺服器之間的相互識別信任。 用戶端憑證會在 TLS 交涉期間使用。 Azure 防火牆會與伺服器重新交涉連線,而且無法存取用戶端憑證的私密金鑰。 | 無 |
QUIC/HTTP3 | QUIC 是 HTTP 新的主要版本。 這是基於 80 (PLAN) 和 443 (SSL) 的 UDP 型通訊協定。 不支援 FQDN/URL/TLS 檢查。 | 將 UDP 80/443 設定為網路規則。 |
未受信任的客戶簽署憑證 | 從內部網路型 Web 服務器接收客戶簽署的憑證之後,防火牆便不再信任該憑證。 | 我們正在調查提供修正程式的可能性。 |
HTTP 的 IDPS 警示來源 IP 位址錯誤 (無 TLS 檢查)。 | 當使用純文字 HTTP 流量,且 IDPS 發出新的警示,而目的地是公用 IP 位址,顯示的來源 IP 位址錯誤 (顯示內部 IP 位址,而不是原始 IP 位址)。 | 我們正在調查提供修正程式的可能性。 |
憑證傳播 | 在防火牆上套用 CA 憑證之後,憑證可能需要 5-10 分鐘才會生效。 | 我們正在調查提供修正程式的可能性。 |
TLS 1.3 支援 | TLS 1.3 部分支援。 從用戶端到防火牆的 TLS 通道是以 TLS 1.2 為基礎,而從防火牆到外部 Web 服務器的 TLS 通道是以 TLS 1.3 為基礎。 | 我們正在調查提供更新的可能性。 |
TLSi 中繼 CA 憑證到期 | 在某些獨特的情況下,中繼 CA 憑證會在原始到期日之前兩個月到期。 | 在原始到期日之前兩個月更新中繼 CA 憑證。 我們正在調查提供修正程式的可能性。 |