Firewalls in a 46Labs SD-WAN Deployment
Recommendation
46Labs recommends deploying the SD-WAN edge devices in parallel to any customer firewall.
Firewalls in a MPLS Deployment
MPLS networks are usually considered a secure environment. The customer’s virtual routing and forwarding (VRF) instance logically separates the customer’s IP traffic traversing the 46Labs MPLS network from all other network traffic. When value add services such as 46Labs SIP Trunking are added to the customer’s VRF, they are done so in a secure manner. Specific to 46Labs SIP Trunking the only IP traffic allowed into or out of the Peeredge Switches 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 by the SIP signaling for the duration of the call.
Although 46Labs believes traditional Firewalls are not required between the customer LAN and the 46Labs 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 46Labs service SLAs will be void if a non-46Labs managed firewall causes a service impairment.
If a firewall is placed between a 46Labs managed SBC/PBX and the MPLS network, the firewall must permit all management traffic (SSH, SNMP, SYSLOG, TFTP, FTP, SCP, ICMP, etc.) between the SBC/PBX and the 46Labs management network. All SBC/PBX management related SLAs will be void if a non-46Labs managed firewall prevents access to the 46Labs 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 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 Switches. 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 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 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. The 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 sent to the Peeredge Switches. For all inbound SIP messages from the Peeredge Switches and outbound facing dial-peers to swap the SBC/PBX IP with public NAT IP in all relevant SIP Headers. The Peeredge Switches will only communicate to the SBC/PBX via the public NAT IP or FQDN (which resolves to the public IP address).
Recommendation
46Labs only recommends putting an SBC/PBX behind a customer firewall in the PBX/SBC supports an ALG function.