Configuring Azure Network Security Groups
Access to Azure instances is restricted by the Azure firewall. This may be configured by associating a subnet or instance with a Network Security Group which specifies the permitted inbound and outbound traffic from the group.
A minimal security group that permits access to a public-cloud style Pexip Infinity deployment is described below and is defined within the Azure Resource Manager (ARM) templates that we provide.
Inbound security rules
These rules allow administrative/management access to the Management Node and Conferencing Nodes, and allow call signaling and media to Conferencing Nodes:
Priority | Name | Source | Destination | Service | Action |
---|---|---|---|---|---|
105 | HTTP | Any | Any | TCP/80 | Allow |
110 | HTTPS | Any | Any | TCP/443 | Allow |
115 | H.323 CS | Any | Any | TCP/1720 | Allow |
120 | SIP TCP | Any | Any | TCP/5060 | Allow |
125 | SIP TLS | Any | Any | TCP/5061 | Allow |
130 | TCP call signaling | Any | Any | TCP/33000-39999 | Allow |
135 | TCP call media | Any | Any | TCP/40000-49999 | Allow |
140 | H.323 LS | Any | Any | UDP/1719 | Allow |
145 | SIP UDP |
Any | Any | UDP/5060 | Allow |
150 | UDP call signaling | Any | Any | UDP/33000-39999 | Allow |
155 | UDP call media | Any | Any | UDP/40000-49999 | Allow |
160 | Management traffic | CIDR block: <management station IP address/subnet> | Any | Any/Any | Allow |
|
Where Any implies any source/destination and <management station IP address/subnet> should be restricted to a single IP address or subnet for management access only.
Outbound security rules
The default Azure network security group rules suffice. These permit outbound traffic to the same Virtual Network, or to the Internet.
A single security group can be applied to the Management Node and all Conferencing Nodes. However, if you want to apply further restrictions to your Management Node (for example, to exclude the TCP/UDP signaling and media ports), then you can configure additional security groups and use them as appropriate for each Azure instance.
Remember that the Management Node and all Conferencing Nodes must be able to communicate with each other. If your instances only have private addresses, ensure that the necessary external systems such as NTP and DNS servers are routable from those nodes.
For further information on the ports and protocols specified here, see Pexip Infinity port usage and firewall guidance.
Deployment scenarios and inter-node communication requirements for multiple Virtual Networks
In a basic deployment, your Pexip Infinity platform will be deployed within a single Azure Virtual Network (VNet).
In larger deployments you may choose to deploy your Conferencing Nodes across multiple VNets — in which case there must be a directly routable path (no NAT) between all nodes that allows UDP port 500 (IKE), and IP Protocol 50 (IPsec ESP) to pass between all nodes in both directions.
These routing requirements and their influence on the various deployment models is as follows:
- Public/private cloud on a single Azure virtual network: the Management Node and Conferencing Nodes are all within the same virtual network and communicate with each other within the network over IPsec which is allowed by default within the VNet.
- Hybrid cloud on a single Azure virtual network: as for public/private cloud above, except that your VPN tunnel must allow the IPsec traffic between your on-premises nodes and your cloud-hosted nodes.
- Conferencing Nodes spread over multiple Azure virtual networks: you should use Global VNet Peering — this means that all network traffic between the peered virtual networks, including the IPsec traffic between nodes, is private and travels over the Azure backbone. (Do not set up a VNet-to-VNet VPN gateway between each virtual network.)
Note that in all cases the Azure Network Security Group templates that we provide allow call signaling and media connectivity into the Pexip Infinity platform.
Azure Resource Manager (ARM) templates for deploying a security group
Pexip provides two ARM templates — one with, and one without, SIP UDP access enabled — which may be used to deploy a security group containing the above rules. These templates may be used from PowerShell or the Azure CLI. Alternatively, you may use the Azure Portal to deploy a security group using the relevant template (see below).
The details of each template are as follows. You should pick the one most suitable for your needs.
Name | SIP UDP access | Template URL | Resources created |
---|---|---|---|
security-group | Disabled |
https://pexipas.blob.core.windows.net/templates/20230124/security-group.json |
Network security group |
security-group-with-sip-udp | Enabled |
https://pexipas.blob.core.windows.net/templates/20230124/security-group-with-sip-udp.json |
Network security group |
Both templates contain the following parameters:
Name | Description |
---|---|
managementNetwork | Network from which to permit management traffic (CIDR notation e.g. 198.51.100.1/32). |
securityGroupName | Name of the security group to create. |
Creating a Network Security Group via the Azure portal
To set up a Network Security Group via the Azure portal:
- Select the appropriate ARM Template URL link from the table above and sign in to the Azure portal if required.
- Select your Subscription and Resource group.
-
Supply the template parameters (Settings):
- The Management Network from which to permit management traffic (CIDR notation e.g. 198.51.100.1/32).
- The Security Group Name.
- Agree to the legal terms.
- Select .