Mục Lục

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 Node

s 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 Node

s 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/20220920/security-group.json

(launch in Azure Portal)

Network security group

security-group-with-sip-udp
Enabled

https://pexipas.blob.core.windows.net/templates/20220920/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:

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
Purchase

.