다음을 통해 공유

Azure Firewall 알려진 문제 및 제한 사항

  • 아티클

이 문서에서는 Azure Firewall의 알려진 문제를 나열합니다. 문제가 해결되면 업데이트됩니다.

Azure Firewall 제한 사항은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.

Azure Firewall Standard

Azure Firewall Standard에는 다음과 같이 알려진 문제가 있습니다.

참고 항목

Standard에 적용되는 모든 문제는 Premium 적용됩니다.

문제 설명 완화
표준 및 프리미엄 버전으로 제한된 개인 IP 주소에 대한 DNAT 지원 Azure Firewall 개인 IP 주소에서 DNAT에 대한 지원은 엔터프라이즈용이므로 표준 및 프리미엄 방화벽 버전으로 제한됩니다. None
TCP/UDP 프로토콜이 아닌 프로토콜(예: ICMP)에 대한 네트워크 필터링 규칙은 인터넷 바운드 트래픽에 작동하지 않습니다. TCP/UDP 프로토콜이 아닌 프로토콜에 대한 네트워크 필터링 규칙은 공용 IP 주소에 대한 SNAT에 작동하지 않습니다. TCP/UDP 프로토콜이 아닌 프로토콜은 스포크 서브넷과 VNet 간에 지원됩니다. Azure Firewall은 표준 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 Application Gateway와 같은 서비스를 사용합니다. Azure Front Door의 일부로 WAF를 추가하고 방화벽에 체인을 추가할 수도 있습니다.
프록시 모드(포트 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 트래픽이 차단됨 TCP 포트 25에서 외부 도메인(예: outlook.com 및 gmail.com)으로 직접 전송되는 아웃바운드 이메일 메시지는 Azure 플랫폼에 의해 차단됩니다. 이는 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개를 지원합니다. 기본적으로 두 개의 가상 머신 확장 집합 인스턴스가 있습니다. 따라서 흐름당 4,992개의 포트(대상 IP, 대상 포트 및 프로토콜(TCP 또는 UDP))가 있습니다. 방화벽은 최대 20개의 인스턴스까지 확장됩니다. 이는 플랫폼 제한 사항입니다. SNAT이 소모될 수 있는 배포에 대해 5개 이상의 공용 IP 주소로 Azure Firewall 배포를 구성하여 제한 사항을 해결할 수 있습니다. 그러면 사용 가능한 SNAT 포트가 5배로 증가합니다. 다운스트림 권한이 간소화되도록 IP 주소 접두사에서 할당합니다. 보다 영구적인 솔루션을 위해 NAT 게이트웨이를 배포하여 SNAT 포트 제한을 극복할 수 있습니다. 이 방법은 가상 네트워크 배포에 대해 지원됩니다.

자세한 내용은 Azure Virtual Network NAT를 사용하여 SNAT 포트 크기 조정을 참조하세요.
DNAT는 강제 터널링을 사용하는 경우 지원되지 않습니다. 강제 터널링을 사용하여 배포된 방화벽은 비대칭 라우팅으로 인해 인터넷에서 인바운드 액세스를 지원할 수 없습니다. 이는 비대칭 라우팅 때문에 의도된 것입니다. 인바운드 연결의 반환 경로는 온-프레미스 방화벽을 통해 전달되며 설정된 연결이 표시되지 않습니다.
아웃바운드 수동 FTP는 FTP 서버 구성에 따라 여러 공용 IP 주소가 있는 방화벽에서 작동하지 않을 수 있습니다. 수동 FTP는 제어 및 데이터 채널에 대해 서로 다른 연결을 설정합니다. 공용 IP 주소가 여러 개인 방화벽이 데이터를 아웃바운드로 보내는 경우 원본 IP 주소에 대한 공용 IP 주소 중 하나를 임의로 선택합니다. FTP 서버 구성에 따라 데이터 및 제어 채널에서 다른 원본 IP 주소를 사용하는 경우 FTP가 실패할 수 있습니다. 명시적 SNAT 구성이 계획되어 있습니다. 그 동안에는 FTP 서버를 구성하여 서로 다른 원본 IP 주소에서 데이터를 허용하고 채널을 제어할 수 있습니다(IIS의 예제 참조). 또는 이 경우에 단일 IP 주소를 사용하는 것이 좋습니다.
FTP 서버 구성에 따라 인바운드 수동 FTP가 작동하지 않을 수 있습니다. 수동 FTP는 제어 및 데이터 채널에 대해 서로 다른 연결을 설정합니다. Azure Firewall의 인바운드 연결은 대칭 라우팅을 보장하기 위해 방화벽 개인 IP 주소 중 하나에 SNAT됩니다. FTP 서버 구성에 따라 데이터 및 제어 채널에서 다른 원본 IP 주소를 사용하는 경우 FTP가 실패할 수 있습니다. 원래 원본 IP 주소를 유지하는 동안 조사하고 있습니다. 그 동안에는 FTP 서버를 구성하여 서로 다른 원본 IP 주소에서 데이터를 허용하고 채널을 제어할 수 있습니다.
FTP 클라이언트가 인터넷을 통해 FTP 서버에 연결해야 하는 경우에는 활성 FTP가 작동하지 않습니다. 활성 FTP는 FTP 서버에 데이터 채널에 사용할 IP 및 포트를 지시하는 FTP 클라이언트의 포트 명령을 활용합니다. 이 포트 명령은 변경할 수 없는 클라이언트의 개인 IP를 활용합니다. Azure Firewall을 통과하는 클라이언트 쪽 트래픽은 인터넷 기반 통신을 위한 NAT로, FTP 서버에서는 PORT 명령을 잘못된 것으로 표시합니다. 이는 클라이언트 쪽 NAT와 함께 사용할 때 활성 FTP의 일반적인 제한 사항입니다.
NetworkRuleHit 메트릭에 프로토콜 차원이 누락됨 ApplicationRuleHit 메트릭은 필터링 기반 프로토콜을 허용하지만 해당 NetworkRuleHit 메트릭에는 이 기능이 없습니다. 수정 사항을 조사하고 있습니다.
64000에서 65535 사이의 포트를 사용하는 NAT 규칙이 지원되지 않음 Azure Firewall은 네트워크 및 애플리케이션 규칙에서 1-65535 범위의 모든 포트를 허용하지만 NAT 규칙은 1-63999 범위의 포트만 지원합니다. 이 문제가 현재 제한 사항입니다.
구성 업데이트는 평균 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 지원은 조사 중에 있습니다.
여러 IP 그룹 업데이트가 충돌 오류로 인해 실패합니다. 동일한 방화벽에 연결된 IP 그룹을 두 개 이상 업데이트하면 리소스 중 하나가 실패한 상태가 됩니다. 이는 알려진 문제/제한 사항입니다.

IP 그룹을 업데이트하면 IP 그룹이 연결된 모든 방화벽에 대한 업데이트가 트리거됩니다. 방화벽이 여전히 ‘업데이트 중’ 상태에 있는 동안 두 번째 IP 그룹에 대한 업데이트를 시작하면 IP 그룹 업데이트가 실패합니다.

오류를 방지하려면 동일한 방화벽에 연결된 IP 그룹을 한 번에 하나씩 업데이트해야 합니다. 업데이트 사이에 충분한 시간을 허용하여 방화벽이 업데이트 상태를 벗어날 수 있도록 합니다.
ARM 템플릿을 사용한 RuleCollectionGroups 제거는 지원되지 않습니다. ARM 템플릿을 사용한 RuleCollectionGroup 제거는 지원되지 않으며 실패합니다. 이것은 지원되는 작업이 아닙니다.
임의(*) 허용에 대한 DNAT 규칙은 SNAT트래픽을 발생시킵니다. DNAT 규칙이 원본 IP 주소로 임의(*)를 허용하는 경우 암시적 네트워크 규칙은 VNet-VNet 트래픽과 일치하고 항상 SNAT 트래픽을 발생시킵니다. 이 문제가 현재 제한 사항입니다.
보안 공급자가 있는 보안 가상 허브에 DNAT 규칙을 추가하는 것은 지원되지 않습니다. 이로 인해 보안 공급자로 이동하는 DNAT 트래픽을 반환하는 비동기 경로가 생성됩니다. 지원되지 않습니다.
2,000개를 초과하는 규칙 컬렉션을 만드는 동안 오류가 발생했습니다. NAT/애플리케이션 또는 네트워크 규칙 컬렉션의 최대 수는 2,000개(리소스 관리자 한도)입니다. 이 문제가 현재 제한 사항입니다.
HTTP/S의 XFF 헤더 XFF 헤더는 방화벽에서 볼 수 있는 원래 원본 IP 주소로 덮어씁니다. 이는 다음 사용 사례에 적용됩니다.
- HTTP 요청
- TLS 종료를 사용하는 HTTPS 요청		 수정 사항을 조사하고 있습니다.
새로 만든 공용 IP 주소를 사용하여 가용성 영역이 있는 방화벽을 배포할 수 없음 가용성 영역이 있는 방화벽을 배포하는 경우 새로 만든 공용 IP 주소를 사용할 수 없습니다. 먼저 새 영역 중복 공용 IP 주소를 만든 다음, 방화벽 배포 중에 이전에 만든 IP 주소를 할당합니다.
북유럽의 물리적 영역 2는 방화벽 배포에 사용할 수 없습니다. 물리적 영역 2로는 새 방화벽을 배포할 수 없습니다. 또한 물리적 영역 2에 배포된 기존 방화벽을 중지하면 다시 시작할 수 없습니다. 자세한 내용은 물리적 및 논리적 가용성 영역을 참조하세요. 새 방화벽의 경우 나머지 가용성 영역을 사용하여 배포하거나 다른 지역을 사용합니다. 기존 방화벽을 구성하려면 배포 후 가용성 영역을 구성하는 방법을 참조하세요.

Azure Firewall 프리미엄

Azure Firewall 프리미엄에는 다음과 같이 알려진 문제가 있습니다.

문제 설명 완화
ESNI는 HTTPS에서 FQDN 해결을 위해 지원됩니다. 암호화된 SNI는 HTTPS 핸드셰이크에서 지원되지 않습니다. 오늘날 Firefox만 사용자 지정 구성을 통해 ESNI를 지원합니다. 제안된 해결 방법은 이 기능을 사용하지 않도록 설정하는 것입니다.
클라이언트 인증(Client Certification) 인증은 지원되지 않습니다. 클라이언트 인증서는 클라이언트와 서버 간에 상호 ID 신뢰를 구축하는 데 사용합니다. 클라이언트 인증서는 TLS 협상 중에 사용합니다. Azure Firewall은 서버와의 연결을 재협상하고 클라이언트 인증서의 프라이빗 키에 액세스할 수 없습니다. 없음
QUIC/HTTP3 QUIC는 HTTP의 새 주 버전입니다. 80(PLAN)과 443(SSL)을 통한 UDP 기반 프로토콜입니다. FQDN/URL/TLS 검사는 지원되지 않습니다. UDP 80/443을 네트워크 규칙으로 전달하도록 구성합니다.
신뢰할 수 없는 고객 서명 인증서 고객이 서명한 인증서는 인트라넷 기반 웹 서버에서 수신되면 방화벽에서 신뢰되지 않습니다. 수정 사항을 조사하고 있습니다.
HTTP에 IDPS를 사용하는 경고에 잘못된 원본 IP 주소가 있습니다(TLS 검사 없음). 일반 텍스트 HTTP 트래픽이 사용 중이고 IDPS가 새 경고를 발행하며 대상이 공용 IP 주소인 경우, 표시된 원본 IP 주소가 잘못된 것입니다(원래 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 인증서를 갱신합니다. 수정 사항을 조사하고 있습니다.

다음 단계