Firewall Considerations

Customer Firewalls in a 46 Labs Voice Firewall Deployment

Recommendation

46 Labs recommends deploying Voice Firewalls in parallel with any customer firewall.

Firewalls in an MPLS Deployment

MPLS networks are usually considered a secure environment. The customer’s virtual routing and forwarding (VRF) instance logically separate the customer’s IP traffic traversing the 46 Labs MPLS network from all other network traffic. When value-added services such as 46 Labs SIP Trunking are added to the customer’s VRF, they are done so in a secure manner. Specific to 46 Labs SIP Trunking, the only IP traffic allowed in or out of the Peeredge SBC is the SIP signaling to and from the configured customer’s SIP Trunking devices (i.e. SBCs/PBXs based on IP Address Authentication or SIP Registration) and the associated RTP media streams set up by the SIP signaling for the duration of the call.

Although 46 Labs believes traditional firewalls are not required between the customer LAN and the 46 Labs MPLS network, they may be required to meet an individual customer’s security policies. Customers may require a firewall between the SBC/PBX and the MPLS network, between the SBC/PBX and the SBC/PBX cluster, or on both sides of the SBC/PBX.

Only fully SIP-aware firewalls should be used. All 46 Labs service SLAs are void if a non-46 Labs managed firewall causes a service impairment.

If a firewall is placed between a 46 Labs managed SBC/PBX and the MPLS network, the firewall must permit all management traffic (e.g. SSH, SNMP, SYSLOG, TFTP, FTP, SCP, ICMP, etc.) between the SBC/PBX and the 46 Labs management network. All SBC/PBX management-related SLAs are void if a non-46 Labs managed firewall prevents access to the 46 Labs managed SBC/PBX.

If the firewall is not fully SIP-aware, it must be configured to allow inbound RTP traffic (UDP ports 5500 to 65000) from the Peeredge SBC for SIP Trunking in the US. 

Firewalls in an Internet Deployment

If the SBC/PBX has a direct internet-facing interface with a dedicated publicly routable IP address, then typically, the SBC/PBX inherent firewall capabilities can provide sufficient protection by accepting only TLS encrypted SIP and Secure RTP media traffic from the Peeredge SBC. In this approach, the SBC/PBX is logically in parallel with any customer firewall protecting their non-voice traffic. If the SBC/PBX does not have any inherent firewall capabilities, this deployment method is not recommended. 46 Labs supports but does not recommend TCP or UDP transport protocols when using Internet transport.

If the SBC/PBX is behind the customer firewall, then any SIP-aware functionality should be disabled, and a one-to-one NAT must be configured on the firewall to allow the TLS-encrypted SIP and Secure RTP media traffic to traverse the firewall. Also, the SBC/PBX must be able to support an application layer gateway (ALG) function. This means the SBC/PBX must be able to change any SBC/PBX IP address in the SIP messages with that of the Public IP address assigned to the SBC/PBX for all SIP messages sent to the Peeredge SBC.  For all inbound SIP messages from the Peeredge SBC and outbound facing dial-peers to swap the SBC/PBX IP with public NAT IP in all relevant SIP Headers. The Peeredge SBC only communicates with the SBC/PBX via the public NAT IP or FQDN (which resolves to the public IP address).

Recommendation

46 Labs recommends putting an SBC/PBX behind a customer firewall in the PBX/SBC supports an ALG function.