이 문서는 Azure Firewall의 현재 알려진 문제 및 제한 사항을 이해하는 데 도움이 됩니다. 문제가 해결되면 이 정보를 업데이트하므로 정기적으로 최신 상태를 확인하세요.
Azure Firewall을 배포하거나 기존 배포 문제를 해결하기 전에 이러한 알려진 문제를 검토하여 일반적인 문제를 방지하고 적절한 해결 방법을 계획합니다.
Azure Firewall 서비스 제한은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
현재 용량 제약 조건
다음 영역에는 현재 용량 제약 조건이 있습니다.
| 지역/영역 | SKU | 제한 | 권장 |
|---|---|---|---|
| 미국 동부 2 EUAP의 물리적 영역 1 및 영역 4 | Basic, Standard 및 Premium | - 영역 1 및 영역 4에 새 Azure Firewall을 배포할 수 없습니다. | 남은 사용 가능 시간 영역에 새로운 Azure Firewall을 배포하거나 다른 지역을 사용하는 것이 좋습니다. 기존 방화벽을 구성하려면 배포 후 가용성 영역을 구성하는 방법을 참조하세요. |
|
-
북유럽의 실제 영역 2 - 동남 아시아의 실제 영역 3 |
표준 및 프리미엄 | - 동남 아시아의 영역 3이나 북유럽의 영역 2에는 새로운 Azure Firewall을 배포할 수 없습니다.
- 이 영역에 배포된 기존 Azure Firewall을 중지하면 다시 시작할 수 없습니다. 자세한 내용은 물리적 및 논리적 가용성 영역을 참조하세요. |
남은 사용 가능 시간 영역에 새로운 Azure Firewall을 배포하거나 다른 지역을 사용하는 것이 좋습니다. 기존 방화벽을 구성하려면 배포 후 가용성 영역을 구성하는 방법을 참조하세요. |
| 미국 중남부의 물리적 영역 3 | Basic, Standard 및 Premium | - 영역 3에서 새 Azure Firewall을 배포할 수 없습니다.
사용 가능한 예상 날짜: 2026년 3월 31일 |
남은 사용 가능 시간 영역에 새로운 Azure Firewall을 배포하거나 다른 지역을 사용하는 것이 좋습니다. 기존 방화벽을 구성하려면 배포 후 가용성 영역을 구성하는 방법을 참조하세요. |
| 스페인 중부의 물리적 존 2 | Basic, Standard 및 Premium | - 영역 2에서 새 Azure Firewall을 배포할 수 없습니다.
사용 가능한 예상 날짜: 2026년 12월 31일 |
남은 사용 가능 시간 영역에 새로운 Azure Firewall을 배포하거나 다른 지역을 사용하는 것이 좋습니다. 기존 방화벽을 구성하려면 배포 후 가용성 영역을 구성하는 방법을 참조하세요. |
| US Gov 버지니아 | Premium | - US Gov 버지니아에는 Azure Firewall Premium SKU에 대한 용량이 0개이며 영역 배포와 비존 배포가 모두 차단됩니다. | Azure Firewall 표준 SKU를 배포하거나 프리미엄 SKU를 다른 지역에 배포합니다. |
| US Gov 버지니아의 실제 영역 3 | 기본 및 표준 | - 영역 배포는 US Gov 버지니아의 물리적 영역 3에서 차단됩니다.
- 성공적인 배포를 위해 사용 가능한 영역을 수동으로 선택해야 하며, 이는 덜 최적화된 배포 환경을 초래할 수 있습니다. |
영역 배포에 대해 영역 1과 2를 선택하거나 다른 지역을 사용합니다. |
| 미국 서부 2의 물리적 영역 2 | Basic, Standard 및 Premium | - 영역 2에서 새 Azure Firewall을 배포할 수 없습니다. | 남은 사용 가능 시간 영역에 새로운 Azure Firewall을 배포하거나 다른 지역을 사용하는 것이 좋습니다. 기존 방화벽을 구성하려면 배포 후 가용성 영역을 구성하는 방법을 참조하세요. |
경고
이러한 용량 제한 지역에서 기존 Azure Firewall 배포를 중지하는 경우 지속적인 용량 제한으로 인해 다시 시작하지 못할 수 있습니다. 이러한 지역에서 방화벽 인스턴스를 중지하기 전에 적절하게 계획합니다.
Azure Firewall 표준 알려진 문제
Azure Firewall Standard에는 다음과 같이 알려진 문제가 있습니다.
| 문제 | 설명 | 완화 방법 |
|---|---|---|
| 표준 및 프리미엄 버전으로 제한된 개인 IP 주소에 대한 DNAT 지원 | Azure Firewall 개인 IP 주소의 DNAT에 대한 지원은 기본 버전이 아닌 표준 및 프리미엄 방화벽 버전에서만 사용할 수 있습니다. | 없음 |
| 개인 IP DNAT 규칙이 구성된 경우 Azure Firewall 할당 취소 및 할당 프로세스가 지원되지 않음 | 프라이빗 DNAT 규칙이 구성되면 Azure Firewall 할당 프로세스가 실패합니다. | 1. Azure Firewall 할당 취소 2. 모든 개인 IP DNAT 규칙 3을 삭제합니다. Azure Firewall을 할당하고 개인 IP가 채워질 때까지 기다립니다. 4. 적절한 개인 IP 주소를 사용하여 개인 IP DNAT 규칙 다시 구성 |
| TCP/UDP 프로토콜이 아닌 프로토콜(예: ICMP)에 대한 네트워크 필터링 규칙은 인터넷 바운드 트래픽에 작동하지 않습니다. | TCP/UDP 프로토콜이 아닌 프로토콜에 대한 네트워크 필터링 규칙은 공용 IP 주소에 대한 SNAT에 작동하지 않습니다. TCP/UDP 프로토콜이 아닌 프로토콜은 스포크 서브넷과 VNet 간에 지원됩니다. | Azure Firewall은 표준 Load Balancer를 사용하기 때문에 현재 IP 프로토콜을 위한 SNAT를 지원하지 않습니다. 향후 릴리스에서는 인터넷 바인딩된 트래픽에 대해 TCP/UDP 이외의 프로토콜을 지원하는 옵션을 모색하고 있습니다. |
| Azure Firewall이 할당 취소된 후 다시 할당되면 새 개인 IP 주소가 할당될 수 있습니다. | Azure Firewall의 할당 해제 및 할당 과정이 완료된 후, Azure Firewall 서브넷에서 개인 IP 주소가 동적으로 할당됩니다. 이전 주소와 다른 새 개인 IP 주소가 할당되면 라우팅 문제가 발생합니다. | 기존 UDR(사용자 정의 경로)을 새 개인 IP 주소로 다시 구성해야 합니다. 할당 프로세스 후에 개인 IP 주소를 유지하기 위한 수정 사항이 조사되고 있습니다. |
| 자식 방화벽 정책은 부모 정책에서 DNS 설정을 상속하지 않습니다. | 부모 방화벽 정책에서 DNS 설정을 변경하면 이에 연결된 자식 정책이 규칙 내 도메인 이름을 해결하지 못할 수 있습니다. | 부모 정책에 의존하지 않고 각 자식 정책에서 직접 DNS 설정을 구성합니다. DNS 설정의 상속을 허용하는 수정 작업을 진행 중입니다. |
| 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를 추적하려면 XFF 헤더에 원래 IP를 포함하도록 클라이언트 또는 프록시 서버를 구성합니다. Azure Firewall은 이러한 IP 주소를 XFF 헤더에 유지하고 웹 트래픽 규칙을 처리할 때 XFF 헤더에 방화벽 IP를 추가합니다. |
| 프록시 모드(포트 1433)에서만 지원되는 SQL FQDN 필터링 | Azure SQL Database, Azure Synapse Analytics 및 Azure SQL Managed Instance의 경우: SQL FQDN 필터링은 프록시 모드에서만 지원됩니다(포트 1433). Azure SQL IaaS의 경우: 비표준 포트를 사용하는 경우 애플리케이션 규칙에서 해당 포트를 지정할 수 있습니다. |
리디렉션 모드의 SQL(Azure 내에서 연결하는 경우 기본값)의 경우 대신 SQL 서비스 태그를 Azure Firewall 네트워크 규칙의 일부로 사용하여 액세스를 필터링할 수 있습니다. |
| TCP 포트 25의 아웃바운드 SMTP 트래픽이 차단됨 | Azure 플랫폼은 TCP 포트 25를 통해 외부 도메인(예: outlook.com 및 gmail.com)으로 직접 전송되는 아웃바운드 이메일 메시지를 차단합니다. 포트 25에서 아웃바운드 SMTP 트래픽을 차단하는 것은 Azure의 기본 플랫폼 동작입니다. Azure Firewall은 더 이상 구체적인 제한을 도입하지 않습니다. |
일반적으로 TCP 포트 587을 통해 연결하지만 다른 포트도 지원하는 인증된 SMTP 릴레이 서비스를 사용합니다. 자세한 내용은 Azure에서 아웃바운드 SMTP 연결 문제 해결을 참조하세요. 또 다른 옵션은 표준 EA(기업계약) 구독에 Azure Firewall을 배포하는 것입니다. EA 구독의 Azure Firewall은 아웃바운드 TCP 포트 25를 사용하여 공용 IP 주소와 통신할 수 있습니다. 다른 구독 유형에서 작동할 수 있지만 보장되지는 않습니다. 가상 네트워크, VPN 및 Azure ExpressRoute와 같은 개인 IP 주소의 경우 Azure Firewall은 TCP 포트 25의 아웃바운드 연결을 지원합니다. |
| SNAT 포트 소모 | Azure Firewall은 현재 백 엔드 Virtual Machine Scale Set 인스턴스별로 공용 IP 주소당 포트 2,496개를 지원합니다. 기본적으로 두 개의 Virtual Machine Scales Set 인스턴스가 있습니다. 따라서 흐름당 4,992개의 포트(대상 IP, 대상 포트 및 프로토콜(TCP 또는 UDP))가 있습니다. 방화벽은 최대 20개의 인스턴스까지 확장됩니다. | SNAT 포트 고갈은 플랫폼 제한 사항입니다. SNAT이 소모될 수 있는 배포에 대해 5개 이상의 공용 IP 주소로 Azure Firewall 배포를 구성하여 제한 사항을 해결할 수 있습니다. 공용 IP 주소를 더 추가하면 사용 가능한 SNAT 포트가 5배 증가합니다. 다운스트림 권한이 간소화되도록 IP 주소 접두사에서 할당합니다. 보다 영구적인 솔루션을 위해 NAT 게이트웨이를 배포하여 SNAT 포트 제한을 극복할 수 있습니다. NAT 게이트웨이 배포는 가상 네트워크 배포에 대해 지원됩니다. 자세한 내용은 Azure Virtual Network NAT를 사용하여 SNAT 포트 크기 조정을 참조하세요. |
| DNAT는 강제 터널링을 사용하는 경우 지원되지 않습니다. | 강제 터널링을 사용하여 배포된 방화벽은 비대칭 라우팅으로 인해 인터넷에서 인바운드 액세스를 지원할 수 없습니다. | 강제 터널링에 대한 DNAT 지원의 부족은 비대칭 라우팅으로 인해 설계되었습니다. 인바운드 연결의 반환 경로는 설정된 연결을 볼 수 없는 온-프레미스 방화벽을 통과합니다. |
| 아웃바운드 수동 FTP는 FTP 서버 구성에 따라 여러 공용 IP 주소가 있는 방화벽에서 작동하지 않을 수 있습니다. | 수동 FTP는 제어 및 데이터 채널에 대해 서로 다른 연결을 설정합니다. 공용 IP 주소가 여러 개인 방화벽이 데이터를 아웃바운드로 보내는 경우 원본 IP 주소에 대한 공용 IP 주소 중 하나를 임의로 선택합니다. FTP 서버 구성에 따라 데이터 및 제어 채널에서 다른 원본 IP 주소를 사용하는 경우 FTP가 실패할 수 있습니다. | 명시적 SNAT 구성이 계획되어 있습니다. 그 동안에는 FTP 서버를 구성하여 서로 다른 원본 IP 주소에서 데이터를 허용하고 채널을 제어할 수 있습니다(IIS의 예제 참조). 또는 FTP 연결 문제가 발생할 때 단일 IP 주소를 사용하는 것이 좋습니다. |
| FTP 서버 구성에 따라 인바운드 수동 FTP가 작동하지 않을 수 있습니다. | 수동 FTP는 제어 및 데이터 채널에 대해 서로 다른 연결을 설정합니다. Azure Firewall의 인바운드 연결은 대칭 라우팅을 보장하기 위해 방화벽 개인 IP 주소 중 하나에 SNAT됩니다. FTP 서버 구성에 따라 데이터 및 제어 채널에서 다른 원본 IP 주소를 사용하는 경우 FTP가 실패할 수 있습니다. | 원래 원본 IP 주소를 유지하는 동안 조사하고 있습니다. 그 동안에는 FTP 서버를 구성하여 서로 다른 원본 IP 주소에서 데이터를 허용하고 채널을 제어할 수 있습니다. |
| FTP 클라이언트가 인터넷을 통해 FTP 서버에 연결해야 하는 경우에는 활성 FTP가 작동하지 않습니다. | 활성 FTP는 FTP 서버에 데이터 채널에 사용할 IP 및 포트를 지시하는 FTP 클라이언트의 포트 명령을 활용합니다. PORT 명령은 변경할 수 없는 클라이언트의 개인 IP를 사용합니다. Azure Firewall을 통과하는 클라이언트 쪽 트래픽은 인터넷 기반 통신을 위한 NAT로, FTP 서버에서는 PORT 명령을 잘못된 것으로 표시합니다. | 활성 FTP 오류는 클라이언트 쪽 NAT와 함께 사용할 때 활성 FTP의 일반적인 제한 사항입니다. |
| NetworkRuleHit 메트릭에 프로토콜 차원이 누락됨 | ApplicationRuleHit 메트릭은 필터링 기반 프로토콜을 허용하지만 해당 NetworkRuleHit 메트릭에는 이 기능이 없습니다. | 수정 사항을 조사하고 있습니다. |
| 64000에서 65535 사이의 포트를 사용하는 NAT 규칙이 지원되지 않음 | Azure Firewall은 네트워크 및 애플리케이션 규칙에서 1-65535 범위의 모든 포트를 허용하지만 NAT 규칙은 1-63999 범위의 포트만 지원합니다. | NAT 규칙 포트에 대한 제한은 현재 제한 사항입니다. |
| 구성 업데이트는 평균 5분이 걸릴 수 있습니다. | Azure Firewall 구성 업데이트는 평균 3 ~ 5분이 걸릴 수 있으며 병렬 업데이트는 지원되지 않습니다. | 수정 사항을 조사하고 있습니다. |
| Azure Firewall은 SNI TLS 헤더를 사용하여 HTTPS 및 MSSQL 트래픽을 필터링합니다. | 브라우저 또는 서버 소프트웨어에서 SNI(서버 이름 표시기) 확장을 지원하지 않는 경우 Azure Firewall을 통해 연결할 수 없습니다. | 브라우저 또는 서버 소프트웨어에서 SNI를 지원하지 않는 경우 애플리케이션 규칙 대신 네트워크 규칙을 사용하여 연결을 제어할 수 있습니다. SNI를 지원하는 소프트웨어는 서버 이름 표시를 참조하세요. |
| 포털 또는 ARM(Azure Resource Manager) 템플릿을 사용하여 방화벽 정책 태그를 추가할 수 없음 | Azure Firewall 정책에는 Azure Portal 또는 ARM 템플릿을 사용하여 태그를 추가할 수 없도록 하는 패치 지원 제한이 있습니다. 다음 오류가 생성됩니다. 리소스에 대한 태그를 저장할 수 없습니다. | 수정 사항을 조사하고 있습니다. 또는 Azure PowerShell cmdlet Set-AzFirewallPolicy를 사용하여 태그를 업데이트할 수 있습니다. |
| IPv6은 현재 지원되지 않습니다. | 규칙에 IPv6 주소를 추가하면 방화벽이 실패합니다. | IPv4 주소만 사용합니다. IPv6 지원은 조사 중에 있습니다. |
| ARM 템플릿을 사용한 RuleCollectionGroups 제거는 지원되지 않습니다. | ARM 템플릿을 사용한 RuleCollectionGroup 제거는 지원되지 않으며 실패합니다. | ARM 템플릿을 사용하여 RuleCollectionGroup을 제거하는 작업은 지원되지 않습니다. |
| DNAT 규칙 중 any (*)를 허용하는 규칙은 SNAT 트래픽을 발생시킵니다. | DNAT 규칙이 원본 IP 주소로 any(*)를 허용하는 경우, 암시적 네트워크 규칙이 VNet-VNet 트래픽에 일치하며 항상 트래픽을 SNAT합니다. | 모든 소스를 가진 DNAT 규칙에 대한 자동 SNAT 동작은 현재 제한 사항입니다. |
| 보안 공급자가 있는 보안 가상 허브에 DNAT 규칙을 추가하는 것은 지원되지 않습니다. | 보안 공급자를 사용하여 보안 가상 허브에 DNAT 규칙을 추가하면 반환되는 DNAT 트래픽에 대한 비동기 경로가 생성되며, 이 경로는 보안 공급자에게 전달됩니다. | 지원되지 않습니다. |
| 2,000개를 초과하는 규칙 컬렉션을 만드는 동안 오류가 발생했습니다. | NAT/애플리케이션 또는 네트워크 규칙 컬렉션의 최대 수는 2,000개(리소스 관리자 한도)입니다. | 2,000개의 규칙 컬렉션 제한은 현재 제한 사항입니다. |
| 새로 만든 공용 IP 주소를 사용하여 가용성 영역이 있는 방화벽을 배포할 수 없음 | 가용성 영역이 있는 방화벽을 배포하는 경우 새로 만든 공용 IP 주소를 사용할 수 없습니다. | 먼저 새 영역 중복 공용 IP 주소를 만든 다음, 방화벽 배포 중에 이전에 만든 IP 주소를 할당합니다. |
| 공용 IP 주소를 Azure Firewall과 연결해도 테넌트 간 시나리오에서는 지원되지 않습니다. | 테넌트 A에서 공용 IP 주소를 만드는 경우 테넌트 B에 배포된 방화벽과 연결할 수 없습니다. | 없음. |
| Azure Firewall 뒤에 있는 VM은 방화벽의 공용 IP를 사용하여 DNAT 규칙 대상에 연결할 수 없습니다. | VM이 Azure Firewall을 통해 트래픽을 라우팅하고 방화벽의 공용 IP 주소를 사용하여 DNAT 규칙으로 구성된 리소스에 연결하려고 하면 연결이 실패합니다. 연결 실패는 Azure Firewall이 DNAT 규칙 대상에 대한 내부 VM에서 방화벽 자체의 공용 IP 주소로의 헤어피닝 트래픽을 지원하지 않기 때문에 발생합니다. | 이 제한에 대한 솔루션은 현재 개발 중입니다. |
Azure Firewall Premium 알려진 문제
참고
Standard에 적용되는 모든 문제는 Premium 적용됩니다.
Azure Firewall 프리미엄에는 다음과 같이 알려진 문제가 있습니다.
| 문제 | 설명 | 완화 방법 |
|---|---|---|
| ESNI는 HTTPS에서 FQDN 해결을 위해 지원됩니다. | 암호화된 SNI는 HTTPS 핸드셰이크에서 지원되지 않습니다. | 오늘날 Firefox만 사용자 지정 구성을 통해 ESNI를 지원합니다. 제안된 해결 방법은 ESNI 기능을 사용하지 않도록 설정하는 것입니다. |
| 클라이언트 인증(Client Certification) 인증은 지원되지 않습니다. | 클라이언트 인증서는 클라이언트와 서버 간에 상호 ID 신뢰를 구축하는 데 사용합니다. 클라이언트 인증서는 TLS 협상 중에 사용합니다. Azure Firewall은 서버와의 연결을 재협상하고 클라이언트 인증서의 프라이빗 키에 액세스할 수 없습니다. | 없음 |
| QUIC/HTTP3 | QUIC는 HTTP의 새 주 버전입니다. 80(PLAN)과 443(SSL)을 통한 UDP 기반 프로토콜입니다. FQDN/URL/TLS 검사는 지원되지 않습니다. | UDP 80/443을 네트워크 규칙으로 전달하도록 구성합니다. |
| 신뢰할 수 없는 고객 서명 인증서 | 방화벽은 인트라넷 기반 웹 서버에서 수신할 때 고객 서명된 인증서를 신뢰하지 않습니다. | 수정 사항을 조사하고 있습니다. |
| IDPS는 TLS 검사 없이 HTTP 경고에 대한 잘못된 원본 IP 주소를 표시합니다. | IDPS가 공용 IP 주소에 대한 일반 텍스트 HTTP 트래픽에 대한 경고를 생성하면 원래 원본 IP 주소 대신 내부 IP 주소가 표시됩니다. | 수정 사항을 조사하고 있습니다. |
| 인증서 전파 | CA 인증서가 방화벽에 적용된 후 인증서가 적용되는 데 5-10분 정도 걸릴 수 있습니다. | 수정 사항을 조사하고 있습니다. |
| TLS 1.3 지원 | TLS 1.3은 부분적으로 지원됩니다. 클라이언트에서 방화벽으로의 TLS 터널은 TLS 1.2를 기반으로 하고, 방화벽에서 외부 웹 서버로의 TLS 터널은 TLS 1.3을 기반으로 합니다. | 업데이트는 조사 중입니다. |
| TLSi 중간 CA 인증서 만료 | 일부 고유한 경우 중간 CA 인증서는 원래 만료 날짜 2개월 전에 만료할 수 있습니다. | 원래 만료 날짜 2개월 전에 중간 CA 인증서를 갱신합니다. 수정 사항을 조사하고 있습니다. |