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

* Only required if you intend to enable SIP over UDP.

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

(launch in Azure Portal)

 Network security group
security-group-with-sip-udp Enabled

https://pexipas.blob.core.windows.net/templates/20230124/security-group-with-sip-udp.json

(launch in Azure Portal)

 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:

  1. Select the appropriate ARM Template URL link from the table above and sign in to the Azure portal if required.
  2. Select your Subscription and Resource group.

  3. 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.
  4. Agree to the legal terms.
  5. Select Purchase.