Customer Firewalls in a
...
46 Labs Voice Firewall Deployment
Recommendation
46Labs 46 Labs recommends deploying the SD-WAN edge devices Voice Firewalls in parallel to with any customer firewall.
...
Firewalls in
...
an MPLS Deployment
MPLS MPLS networks are usually considered a secure environment. The customer’s virtual routing and forwarding (VRF) instance logically separates separate the customer’s IP traffic traversing the 46Labs 46 Labs MPLS network from all other network traffic. When value add -added services such as 46Labs 46 Labs SIP Trunking are added to the customer’s VRF, they are done so in a secure manner. Specific to 46Labs 46 Labs SIP Trunking, the only IP traffic allowed into in or out of the Peeredge Switches 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 setup set up by the SIP signaling for the duration of the call.
Although 46Labs 46 Labs believes traditional Firewalls firewalls are not required between the customer LAN and the 46Labs 46 Labs MPLS network, they may be required to meet an individual customer’s security policies. Customers 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 46Labs 46 Labs service SLAs will be are void if a non-46Labs 46 Labs managed firewall causes a service impairment.
If a firewall is placed between a 46Labs 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 46Labs 46 Labs management network. All SBC/PBX management-related SLAs will be are void if a non-46Labs 46 Labs managed firewall prevents access to the 46Labs 46 Labs managed SBC/PBX.
If the firewall is not fully SIP-aware then , it must be configured to allow inbound RTP traffic (UDP ports 5500 to 65000) from the Peeredge Switches SBC for SIP Trunking in the US.
Firewalls in an Internet Deployment
If If the SBC/PBX has a direct Internet 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 SwitchesSBC. In 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, then this deployment method is not recommended. 46Labs 46 Labs supports but does not recommend TCP or UDP transport protocols when using Internet transport.
If 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 Also, the SBC/PBX must be able to support an application layer gateway (ALG) function. The 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 message messages sent to the Peeredge SwitchesSBC. For all inbound SIP messages from the Peeredge Switches and SBC and outbound facing dial-peers to swap the SBC/PBX IP with public NAT IP in all relevant SIP Headers. The The Peeredge Switches will only communicate to SBC only communicates with the SBC/PBX via the public NAT IP or FQDN (which resolves to the public IP address).
Recommendation
46Labs only 46 Labs recommends putting an SBC/PBX behind a customer firewall in the PBX/SBC supports an ALG function.
...