깡민쓰~IT Story

다음은 Azure에 Palo Alto의 VM-Series Virtual Appliance를 배포하면서 얻은 몇 가지 반작용을 요약한 것입니다. 이것은 가이드라기보다는 내가 취한 단계를 반영한 것이지만 아래 정보를 적절하다고 생각되는 대로 사용할 수 있습니다. 개략적으로 Azure에 디바이스를 배포한 다음, Azure의 VNet(Virtual Network)에서 트래픽을 적절하게 라우팅할 수 있도록 Palo Alto의 내부 "내장"을 구성해야 합니다. 설명된 단계는 Palo Alto VM-Series 어플라이언스의 8.0 및 8.1 버전 모두에 적용되어야 합니다.

또한 이 자습서에서는 스케일 아웃 아키텍처를 배포하려고 한다고 가정합니다. 이렇게 하면 단일 인스턴스가 푸시하려는 대역폭의 양에 압도되지 않도록 할 수 있습니다. 단일 인스턴스를 찾고 있는 경우에도 계속 따라갈 수 있습니다.

Azure에서 어플라이언스 배포Deploy the appliance in Azure

Virtual Palo Altos를 배포할 때 설명서에서는 Azure Marketplace(https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=Overview 에서 찾을 수 있음)를 통해 만드는 것을 권장합니다. 개인적으로, 나는 명명 규칙에 대한 많은 통제력이 없고, 규모를 위해 둘 이상의 어플라이언스를 배포 할 수 없으며, 가용성 집합을 지정할 수 없으며, 관리 디스크를 활용할 수 없기 때문에 이러한 방식으로 어플라이언스를 배포하는 것을 좋아하지 않습니다. 또한 31자보다 큰 암호를 지정하면 Palo Alto 디바이스가 Azure에 배포되지 않는다는 정말 이상한 오류를 발견했습니다. 이 경우 관리 디스크, 가용성 집합, 일관된 명명법, 적절한 VM 크기 조정을 활용하고 가장 중요한 것은 크기 조정을 위해 배포하려는 가상 인스턴스의 수를 정의할 수 있는 사용자 지정 ARM 템플릿을 작성했습니다.

참고: 이 문서에서는 Panorama를 사용하는 개념을 다루지 않지만, "단일 창"에서 각 스케일 아웃 인스턴스를 중앙에서 관리합니다. 아래에서는 노드를 수동으로 설정하여 작동시키는 방법에 대해 설명합니다. ARM 템플릿 배포 시 노드를 부트스트랩하기 위해 배포 후 Panorama에 조인하는 기본 구성 파일을 생성할 수 있습니다. 부트 스트랩 파일은이 템플릿에 통합 한 것이 아니지만 템플릿을 쉽게 수정할 수 있습니다.

위에서 언급했듯이 이 기사에서는 Palo Alto가 공유 디자인 모델로 간주하는 것을 다룹니다. 다음은 시각적으로 표시되는 것의 예입니다(이 문서 하단의 메모 섹션에 나열된 Palo Alto의 참조 아키텍처 문서에서 발췌).

Palo Alto의 Reference Architecture에 따른 공유 설계 모델

Microsoft에는 가상 어플라이언스 배포를 설명하는 참조 아키텍처 문서도 있으며, 이 문서는 다음에서 찾을 수 있습니다 https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha

아래는 내가 사용하는 ARM 템플릿에 대한 링크입니다.

PaloAlto-HA.json

이 템플릿의 배포는 Azure Portal(portal.azure.com)로 이동하고, 리소스 만들기를 선택하고, Azure Marketplace에서 템플릿 배포를 입력하고, 만들기를 클릭하고, 편집기에서 고유한 템플릿 빌드를 선택하고, 코드를 편집기에 붙여넣어 수행할 수 있습니다.

또는 여기에서 이 버튼을 클릭할 수 있습니다.

다음은 템플릿에서 매개 변수가 의미하는 바에 대한 몇 가지 참고 사항입니다.

VM 크기: Palo Alto에 따라 권장되는 VM 크기는 DS3, DS4 또는 DS5여야 합니다. 이에 대한 설명서는 여기에서 찾을 수 있습니다.

PASku: 여기에서 Bring-Your-Own-License 또는 종량제 사용을 선택할 수 있습니다. 계획은 여기에 요약되어 있습니다 : https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=PlansAndPrice

PAVersion: 배포할 PanOS의 버전입니다.

PACount: 부하 분산 장치 뒤에 배포하고 배치하려는 가상 인스턴스의 수를 정의합니다.

VNetName: 만든 가상 네트워크의 이름입니다.

VNetRG: 가상 네트워크가 있는 리소스 그룹의 이름입니다. 이는 Palos를 배치하는 리소스 그룹과 동일할 수 있지만, 다른 리소스 그룹의 VNet을 참조하는 오류를 방지하기 위해 구성 가능한 필수 옵션입니다.

envPrefix: 생성되는 모든 리소스(로드 밸런서, 가상 머신, 공용 IP, NIC 등)는 이 명명 명명법을 사용합니다.

manPrivateIPPrefix, trustPrivateIPPrefix, untrustPrivateIPPrefix: 해당 서브넷 주소 범위입니다. 이는 범위의 처음 3옥텟 뒤에 마침표가 와야 합니다. 예: 10.5.6. 가 유효한 값입니다.

manPrivateIPFirst, trustPrivateIPFirst, untrustPrivateIPFirst: 지정된 서브넷에서 사용 가능한 첫 번째 IP 주소입니다. 예를 들어 서브넷이 10.4.255.0/24인 경우 첫 번째 사용 가능한 주소로 4를 지정해야 합니다.

사용자 이름: PanOS 웹 포털에 ssh 및 로그인하는 데 사용해야 하는 권한 있는 계정의 이름입니다.

* 암호: PanOS 웹 포털에 ssh 및 로그인하는 데 사용되는 권한 있는 계정의 암호입니다. Pan OS 제한으로 인해 31자 이하여야 합니다.

어플라이언스 구성

가상 어플라이언스가 배포되면 Trust/Untrust 인터페이스에서 연결을 활성화하도록 Palo Alto 디바이스 자체를 구성해야 합니다.

VM-Series 방화벽에서 라이센스를 활성화합니다.

BYOL 버전을 사용하는 경우 다음 단계를 수행합니다

1. 지원 계정을 만듭니다.
2. VM-Series 방화벽
   (인증 코드 포함)을 등록합니다.
3. 방화벽 웹 인터페이스에서 Device(디바이스) 탭 -> Licenses(라이선스)
   를 선택하고 Activate feature using authentication code(인증 코드를 사용하여 기능 활성화)를 선택합니다.
4. 지원
   포털에 등록한 용량 인증 코드를 입력합니다. 방화벽이 업데이트 서버(updates.paloaltonetworks.com)에 연결되고 라이센스가 다운로드
   되고 자동으로 재부팅됩니다. 그래도 문제가 해결되지 않으면 아래에서 장치의 인터페이스 구성을 계속하십시오.
5. 재부팅 후 웹 인터페이스에 다시 로그인하고 대시보드에서 다음을 확인합니다.
   1. 유효한 일련 번호가 Serial#에 표시됩니다.
      알 수 없음이라는 용어가 표시되면 장치에 라이선스가 부여되지 않았음을 의미합니다. 방화벽에서 트래픽 로그를 보려면
      유효한 용량 라이선스를 설치해야 합니다.
   2. VM 모드가 Microsoft Azure로 표시됩니다.

PAYG(Pay as you go) 버전을 사용하는 경우 다음 단계를 수행합니다

1. 지원 계정을 만듭니다.
2. AWS 및 Azure에서 VM 시리즈 방화벽
   의 사용량 기반 모델을 등록합니다(인증 코드 없음).

Untrust/Trust 인터페이스 구성

신뢰할 수 없는 인터페이스 구성

1. Network-> Interfaces ->Ethernet->를 선택하고 ethernet1/1에 대한 링크를 선택한 후 다음과 같이 구성합니다.
   1. 인터페이스 유형: Layer3(기본값).
   2. Config 탭에서 인터페이스를 Untrust-VR 라우터에 할당합니다.
   3. Config(구성) 탭에서 Security Zone(보안 영역) 드롭다운을 확장하고 New Zone(새 영역)을 선택합니다. Untrust(신뢰할 수 없음)라는 새 영역을 정의하고 OK(확인)를 클릭합니다.
2. 인터페이스에 하나의 IP 주소만 할당하려는 경우 IPv4 탭에서 DHCP Client(DHCP 클라이언트)를 선택합니다. 둘 이상의 IP 주소를 할당하려는 경우 고정을 선택하고 Azure Portal의 인터페이스에 할당된 기본 및 보조 IP 주소를 수동으로 입력합니다. 인터페이스의 개인 IP 주소는 Virtual Machines -> YOURPALOMACHINE -> Networking으로 이동하고 각 탭에 지정된 개인 IP 주소를 사용하여 찾을 수 있습니다.
   1. 참고: 가상 머신에 공용 IP 주소를 사용하지 마십시오. Azure는 트래픽을 개인 주소로 자동으로 DNAT하므로 UnTrust 인터페이스에 개인 IP 주소를 사용해야 합니다.
3. Automatically create default route to default gateway provided by server 확인란의 선택을 취소합니다.
   1. 참고: 이 옵션을 사용하지 않도록 설정하면 이 인터페이스에서 처리되는 트래픽이 VNet의 기본 게이트웨이로 직접 흐르지 않습니다.
4. 확인을 클릭합니다.

참고: 신뢰할 수 없는 인터페이스의 경우 템플릿이 배포하지 않으므로 Azure 환경 내에서 신뢰할 수 없는 서브넷 또는 개별 방화벽 인터페이스에 연결된 NSG가 있는지 확인합니다(추가할 수 있지만 이미 NSG가 있는 경우 덮어쓰지 않으려고 합니다). Azure Load Balancer의 설명서에 따라 인터넷에서 들어오는 트래픽을 허용하려면 NIC 또는 서브넷에 연결된 NSG가 필요합니다.

트러스트 인터페이스 구성

1. Network-> Interfaces ->Ethernet->을 선택하고 ethernet1/2에 대한 링크를 선택한 후 다음과 같이 구성합니다.
   1. 인터페이스 유형: Layer3(기본값).
   2. Config 탭에서 Trust-VR 라우터에 인터페이스를 할당합니다.
   3. Config(구성) 탭에서 Security Zone(보안 영역) 드롭다운을 확장하고 New Zone(새 영역)을 선택합니다. Trust(신뢰)라는 새 영역을 정의하고 OK(확인)를 클릭합니다.
2. 인터페이스에 하나의 IP 주소만 할당하려는 경우 IPv4 탭에서 DHCP Client(DHCP 클라이언트)를 선택합니다. 둘 이상의 IP 주소를 할당하려는 경우 고정을 선택하고 Azure Portal의 인터페이스에 할당된 기본 및 보조 IP 주소를 수동으로 입력합니다. 인터페이스의 개인 IP 주소는 Virtual Machines -> YOURPALOMACHINE -> Networking으로 이동하고 각 탭에 지정된 개인 IP 주소를 사용하여 찾을 수 있습니다.
   1. Automatically create default route to default gateway provided by server 확인란의 선택을 취소합니다.
      1. 참고: 이 옵션을 사용하지 않도록 설정하면 이 인터페이스에서 처리되는 트래픽이 VNet의 기본 게이트웨이로 직접 흐르지 않습니다.
3. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다. 인터페이스의 링크 상태가 작동 중인지 확인합니다(Palo Alto 사용자 인터페이스에서 인터페이스가 녹색으로 바뀌어야 함).

Static Routes(정적 경로 정의)

Palo Alto는 트래픽을 인터넷으로 라우팅하는 방법과 서브넷으로 트래픽을 라우팅하는 방법을 이해해야 합니다. 이 섹션에서 볼 수 있듯이 각 Azure Load Balancer에서 제출된 상태 프로브의 처리를 처리하는 데 도움이 되는 두 개의 별도 가상 라우터가 필요합니다.

새 Virtual Router 및 Static Route to the Internet(인터넷에 대한 고정 경로)을 생성합니다.

1. Network(네트워크) - > Virtual Router(가상 라우터)를 선택합니다.
2. 하단에서 추가를 클릭합니다.
3. 이름을 Untrust-VR로 설정합니다.
4. 고정 경로 선택 -> IPv4 -> 추가
5. 인터넷 트래픽을 송신하기 위한 고정 경로 생성
   1. 이름: 인터넷
   2. 대상: 0.0.0.0/0
   3. 인터페이스: 이더넷 1/1
   4. 다음 홉: IP 주소
   5. IP 주소: Untrust 인터페이스가 배포된 서브넷의 기본 게이트웨이 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰할 수 없는 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
6. 정적 경로를 생성하여 인터넷에서 신뢰할 수 있는 VR로 트래픽 이동
   1. 이름: 내부 경로
   2. 대상: vnet 주소 공간
   3. 인터페이스: 없음
   4. 다음 홉: 다음 VR
      1. 트러스트-VR
7. 확인을 클릭합니다.

Azure 서브넷에 대한 새 가상 라우터 및 고정 경로 만들기Create a new Virtual Router and Static Route to your Azure Subnets

1. Network(네트워크) - > Virtual Router(가상 라우터)를 선택합니다.
2. 하단에서 추가를 클릭합니다.
3. 이름을 Trust-VR로 설정합니다.
4. 고정 경로 선택 -> IPv4 -> 추가
5. 신뢰할 수 있는 인터페이스에서 Azure로 트래픽을 보내는 고정 경로 만들기Create a Static Route to send traffic to Azure from your trusted interface
   1. 이름: AzureVNet
   2. 대상: vnet 주소 공간
   3. 인터페이스: 이더넷 1/2
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 트러스트 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
6. Trust에서 수신된 인터넷 트래픽을 Untrust Virtual Router로 이동하기 위한 고정 경로 생성
   1. 이름: 인터넷
   2. 대상: 0.0.0.0/0
   3. 인터페이스: 없음
   4. 다음 홉: 다음 VR
      1. 언트러스트 VR
7. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

Azure Load Balancer에 대한 상태 프로브 구성Configure Health Probes for Azure Load Balancer

스케일 아웃 시나리오를 배포하는 경우 Azure Load Balancer의 IP 주소인 168.63.129.16에서 TCP 프로브를 승인해야 합니다. Azure 상태 프로브는 특정 IP 주소(168.63.129.16)에서 제공됩니다. 이 경우 로드 밸런서에 대한 응답을 다시 허용하기 위해 정적 경로가 필요합니다. 이 문서에서는 Azure Load Balancer가 Palo Alto 인스턴스가 정상인지 확인하기 위해 연결할 수 있도록 Trust 인터페이스에서 SSH를 엄격하게 구성합니다.

인터페이스에 대한 Palo Alto SSH 서비스 구성

먼저 인터페이스 관리 프로필을 생성해야 합니다

1. 네트워크 -> 네트워크 프로파일 -> Interface Mgmt를 선택합니다.
2. 버튼 왼쪽에서 추가를 클릭합니다.
3. 다음 구성을 사용합니다
   1. 이름: SSH-MP
   2. 관리 서비스: SSH
   3. 허용된 IP 주소: 168.63.129.16/32
4. 확인을 클릭합니다.

다음으로 Trust 인터페이스에 프로필을 할당해야 합니다

1. 네트워크 선택 -> 인터페이스 ->ethernet1/2에 대한 링크 선택
2. 고급 탭을 선택합니다.
3. 관리 프로필을 SSH-MP로 설정합니다.
4. 확인을 클릭합니다.

다음으로 Untrust 인터페이스에 프로필을 할당해야 합니다

1. 네트워크 선택 -> 인터페이스 ->ethernet1/1에 대한 링크 선택
2. 고급 탭을 선택합니다.
3. 관리 프로필을 SSH-MP로 설정합니다.
4. 확인을 클릭합니다.

신뢰할 수 없는 인터페이스에서 Azure Load Balancer 상태 프로브에 대한 정적 경로 만들기Create a static route for the Azure Load Balancer Health Probes on the Untrust Interface

다음으로, 0.0.0.0/0 규칙으로 인해 상태 프로브가 Untrust 인터페이스에서 빠져나가도록 지시해야 합니다.

1. 네트워크 -> 가상 라우터 -> Untrust-VR을 선택합니다.
2. 고정 경로 선택 -> IPv4 -> 추가
3. 다음 구성을 사용합니다
   1. 이름: AzureLBHealthProbe
   2. 대상: 168.63.129.16/32
   3. 인터페이스: 이더넷 1/1
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
4. 확인을 클릭합니다.

트러스트 인터페이스에서 Azure Load Balancer 상태 프로브에 대한 고정 경로 만들기Create a static route for the Azure Load Balancer Health Probes on the trust interface

다음으로, 0.0.0.0/0 규칙으로 인해 상태 프로브가 Trust 인터페이스에서 벗어나도록 지시해야 합니다.

1. Network(네트워크) -> Virtual Router(가상 라우터) - Trust(신뢰)> VR을 선택합니다.
2. 고정 경로 선택 -> IPv4 -> 추가
3. 다음 구성을 사용합니다
   1. 이름: AzureLBHealthProbe
   2. 대상: 168.63.129.16/32
   3. 인터페이스: 이더넷 1/2
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
4. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

인터넷으로 향하는 내부 트래픽에 대한 NAT 규칙 만들기

Untrust 인터페이스의 주소를 통해 인터넷으로 향하는 모든 이그레스 트래픽을 NAT해야 하므로 인터넷의 반환 트래픽은 디바이스의 Untrust 인터페이스를 통해 다시 들어옵니다.

1. Policies(정책) - > NAT로 이동합니다.
2. Add(추가)를 클릭합니다.
3. 일반 탭에서 다음 구성을 사용합니다
   1. 이름: UntrustToInternet
   2. 설명: 인터넷으로 향하는 모든 신뢰할 수 있는 트래픽을 신뢰할 수 없는 인터페이스로 NAT하는 규칙
4. Original Packet(원본 패킷) 탭에서 다음 구성을 사용합니다
   1. Source Zone(소스 영역): Add(추가)를 클릭하고 Trust(신뢰)를 선택합니다.
   2. 대상 영역: 신뢰할 수 없음
   3. 대상 인터페이스: 이더넷 1/1
   4. 서비스: 모두 확인
   5. Source Address(소스 주소): Add(추가)를 클릭하고 Trust zone의 Internal Address(내부 주소) 공간을 사용합니다.
   6. 대상 주소: 모두 선택
5. Translated Packet(변환된 패킷) 탭에서 다음 구성을 사용합니다
   1. 변환 유형: 동적 IP 및 포트
   2. 주소 유형: 인터페이스 주소
   3. 인터페이스: 이더넷 1/1
   4. IP 주소: 없음
   5. 대상 주소 변환 변환 유형: 없음
6. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

Palo Alto 어플라이언스 업데이트

기본적으로 Palo Alto는 8.0.X 시리즈에 8.0.0을 배포하고 8.1.X 시리즈에 8.1.0을 배포합니다. 이 경우 Palo Alto는 지원 사례를 지원하기 전에 어플라이언스를 해당 시리즈의 최신 버전으로 업그레이드할 것을 강력히 권장합니다.

이렇게 하려면 Device -> Dynamic Updates로 이동하여 왼쪽 하단의 Check Now를 클릭하고 사용 가능한 업데이트 목록에서 최신 빌드를 다운로드>.

참고: 업데이트 프로세스를 수행하려면 장치를 재부팅해야 하며 20분 정도 걸릴 수 있습니다.

요약

이 시점에서 작동하는 스케일 아웃 Palo Alto 배포가 있어야 합니다. 모든 것이 순조롭게 진행되었다면 관리 인터페이스에서 공용 IP를 제거하거나 최소한 원래 있는 단일 공용 IP 주소로 범위를 지정하는 것이 좋습니다. 여기로 이동하여 공용 IP 주소를 찾을 수 있습니다 https://jackstromberg.com/whats-my-ip-address/

참조

Azure에 VM-Series 배포에 대한 Palo Alto의 공식 문서 (이것을 찾는 데 시간이 오래 걸렸으며 정적 경로 설정 또는 어플라이언스 업데이트는 다루지 않음) : https://docs.paloaltonetworks.com/vm-series/8-1/vm-series-deployment/set-up-the-vm-series-firewall-on-azure/deploy-the-vm-series-firewall-on-azure-solution-template.html

Azure VM 크기 조정에 대한 Palo Alto의 공식 설명서: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClD7CAK

Azure의 VM-Series 아키텍처에 대한 설명서(PDF 복사본을 얻으려면 페이지 맨 위에 있는 작은 다운로드 단추를 클릭): https://www.paloaltonetworks.com/resources/guides/azure-architecture-guide

팔로알토 네트웍스 Visio & OmniGraffle 스텐실: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmAJCA0

Palo Alto에서 스케일 아웃 VM 시리즈 배포의 아키텍처를 간략하게 설명하는 깔끔한 비디오: https://www.paloaltonetworks.com/resources/videos/vm-series-in-azure

Palo Alto 배포의 예정된 VMSS 버전: PaloAltoNetworks/azure-autoscaling: VMSS를 사용하는 Azure 자동 크기 조정 솔루션(github.com)

Now that I have outlined the building blocks of a Lync infrastructure, there are three more topics to understand if we want to have a working infrastructure:

• Firewall rules required to allow communications for Lync clients, Lync servers and for the aforementioned non-Lync servers with additional services we need
• DNS settings to make Lync services available both on the internal network and from the Internet
• Structure of the certificates. Lync is secure by design and digital certificates are mandatory for every Lync 2013 infrastructure

Firewall Rules Required for Lync Server 2013

A deep dive about firewall rules for Lync Server 2013 should include TechNet article Port Requirements http://technet.microsoft.com/en-us/library/gg398798.aspx and the Lync 2013 Protocol Workloads poster http://www.microsoft.com/en-us/download/details.aspx?id=39968 (i.e. to check the requirements for the different scenarios). However to make the topic easier to understand, I have tried to create an explanation based on some assumption.

• The first assumption I will make here is that your network has a segregated DMZ to make services available to the Internet in a secure manner. A couple of the possible solutions for such a deployment are
• Using two firewalls. Note: usually the technology used for the firewalls is not important. However if a SIP trunk is required in our scenario, it is important to have a SIP Application-level gateway (ALG).
• A three-legged firewall that will create a logical demilitarized zone

There is no difference in the result, from the functionality point of view, going for the first option or the second one. A single firewall would imply a single point of failure and higher security risk, because a single Internet-connected device will be exposed both on the DMZ and on the internal network. Having two different firewalls, a front (FW2) and a back firewall (FW1), as shown in figure 6.7, is more secure, especially if we are going to use two different platforms or solutions for security. In the aforementioned scenario, an exploitable security vulnerability on a single technology will not affect the second firewall

A layout including only firewalls and networks that will have an impact on our Lync deployment

Figure 6.7 layout including only firewalls and networks that will have an impact on our Lync deployment

• The second assumption will be that we will not deploy High Availability or load balancing systems (including Enterprise Edition pools of Lync Front Ends). Although you may require them in a real-world design, they add a configuration overhead that will not help understanding the fundamentals of Lync Server 2013 network traffic requirements
• The third assumption is that we will use NAT every time that a public IP is required. Exposing directly a server to the Internet usually is not the best security solution available
• Fourth assumption is that the Edge Server will use three addresses on the “external” network interface card to expose services to the Internet. The addresses are the ones we have already seen:

Edge_IPs

• Last assumption: no integration or connection with Office Communications Server 2007 deployments or clients is required

We will have to grant the following types of network traffic:

6.1 From servers in the DMZ to servers in the internal network

6.2 From servers in the DMZ to the external network

6.3 From the external network to servers in the DMZ

6.4 From servers in internal network to servers in DMZ

6.5 Network traffic related to Lync clients in the internal network

Note: the point 6.5 of the list is interesting only if you have firewalls (or end-point firewalls) separating the networks containing the Lync clients and the Lync servers.

6.1 Network Traffic from servers in The DMZ to Servers in the Internal Network

On the Back-End firewall, FW1,for traffic starting from the reverse proxy, the following ports will be required

On the Back-End firewall, FW1, for traffic starting from the Edge Server, the following ports will be required

6.2 Network Traffic from Servers in the DMZ to the External Network

On the Front firewall, FW2, from the Edge Server, the following ports will be required. It is helpful to remind you the fourth assumption: we have three different IPs on the external network interface of the Lync Edge Server: Access, Webconf and AV. The firewall rules for network traffic from the external network to the Edge will have to point to one of the three IPs, as explained in the following table.

6.3 Network Traffic from the External Network to Servers in the DMZ

On the Front firewall, FW2, traffic from the external network to the reverse proxy, the following ports will be required

On the Front-End firewall, FW2, traffic from the external network to the Edge Server, the following ports will be required

6.4 Network Traffic from Servers in the Internal Network to Servers in the DMZ

On the Back-End firewall, FW1, for traffic starting from the internal network, the following ports will be required

6.5 Network Traffic Related to Lync Clients in the Internal Network

The following rules are required on any end-point firewall and on any internal firewall that controls traffic coming from the Lync clients on the internal network.

Notes Related to the Firewall Rules Required for Lync Server 2013

Lync Server 2013 Edge Server requires DNS resolution and http access to revocation lists of certificates. Depending from your network design, the aforementioned services could be on the Internet or could be available using services on the internal network (like a proxy). The following rule is to be adapted to your network layout

Centralized Logging Service (a new feature in Lync Server 2013) requires additional ports on the back-end firewall (for more details see the TechNet article Using the Centralized Logging Service http://technet.microsoft.com/en-us/library/jj688101.aspx

Disclaimer: please consider the answer as an approximation that could miss some detail. I will try to make a more complete answer in a future post.

Ports required in Lync 2013 (must be reachable from your administrative workstation):
— Ports LDAP (TCP 389) and msft-gc (TCP 3268) on a global catalog/domain controller are always required

-For the Lync Server Control Panel (process is AdminUIHost.exe): HTTPS and TCP 49336 on the Lync server you are going to manage

-For the Lync Server Management Shell (process is powershell.exe): TCP 49336 on the Lync server you are going to manage

-For the Topology Builder to download Lync topology (process is Microsoft.Rtc.Management.TopologyBuilder.exe): TCP 49336 on the Lync server hosting the CMS database

-For the Topology Builder to publish Lync topology (process is Microsoft.Rtc.Management.TopologyBuilder.exe): in addition to the aforementioned ports, Microsoft Directory Services TCP/UDP 445 to a Domain Controller and to the Lync server hosting the CMS database

https://www.absoluteuc.org/part-2-draft-chapter-6-dns-certificate-firewall-requirements-lync-server-2013

http://www.cusoon.fr/sbc-and-sba-guide-ports/