Separation of Untrusted Network Traffic on AudioCodes SBCs


This is the third in a series of articles on hardening AudioCodes Session Border Controllers (SBCs). The series is mostly following the guidance provided by AudioCodes. These articles are listed at the end of this article. 

AudioCodes recommends untrusted network traffic be both physically and logically separated on their SBCs and Media Gateways to enhance the device’s security stance. This is the foundation when hardening these devices. This separation also makes configuration and troubleshooting on the device much easier. Your network security people will be happier with this configuration because it will require fewer rules and open ports for individual public IP addresses on the firewall. It will also reduce the attack surface to each interface. If a network interface on the SBC handles both Teams and Contact Center traffic, an attack on the public IP of the Contact Center will affect your Contact Center and Teams traffic. If separated, the attack would only impact the Contact Center. 

Can this be achieved in all deployments in all cases with your existing SBC? No. Though your existing SBC may have enough horsepower and SBC capacity licenses to meet your needs, the SBC itself may not have enough physical ports to separate all your untrusted network traffic. 

Trusted and Untrusted Network Traffic

AudioCodes defines your Local Area Network (LAN) as a trusted network. The SBC’s interface to your LAN is typically used as the SBCs Management Interface. This interface can be used to interface the SBC to SIP enabled PBXs, Analog Transfer Adapters (ATAs), SIP enabled endpoints, paging interfaces/systems, door access devices, etc. Traffic to these entities is usually not physically separated on SBCs but should be logically separated, not so much for security reasons but for ease of management and troubleshooting. The AudioCodes guidelines presume that customers have their trusted network houses in order as far as security is considered. 

All other networks are treated as untrusted networks. It is essential that you take extreme caution with your untrusted networks. The interfaces to Microsoft Teams and your SIP Trunks are untrusted. Connections to Teams Direct Routing Contact Center Solutions, Dynamic 911 Emergency Response Service Providers (ERSPs), etc. would also be untrusted. Each of these entities should be physically and logically separated on your SBCs. If you have SIP Trunks from different vendors, can you set them up on the same physical interface of the SBC? Yes, should you, no! 

Physical Separation

The most obvious physical component on an SBC is the number of available physical network interfaces: 

And now for the math portion of our show: 

  1. A client owns a Mediant 2600 with eight (8) physical ports.
  2. The first port will be used for the trusted LAN network and SBC management.
  3. That leaves seven (7) ports for up to seven (7) different untrusted networks.


Next, a bit more complex:

  1. The client decides to aggregate two (2) ports for each network to provide resiliency. The aggregation can also provide performance benefits if desired.
  2. The first and second ports are assigned to the trusted network.
  3. That leaves three (3) pairs of ports for up to three (3) different untrusted networks.


And even more complex:

  1. The client owns a pair of Mediant 2600s and wants to setup High Availability (HA) between them.
  2. Each SBC will need at least one network port for HA.
    1. The HA network is usually isolated from all other networks.
    2. The connection between the SBCs is commonly made by connecting ports on both SBCs to each other with a network cable.
    3. It is common to aggregate two (2) physical ports for HA.
  3. We still want to aggregate ports for the other networks.
  4. The first two (2) ports are for the LAN interface, the last two (2) ports are for the HA system.
  5. This leaves us with two (2) pair of ports for up to two (2) different untrusted networks.


It is easy to see that we can quickly run out of physical ports on an SBC.

We worked with a customer with a highly available pair of Mediant 4000s with eight (8) ports each. They had four (4) untrusted networks they needed to contact to:

  • A SIP Trunk
  • Microsoft Teams
  • A Teams Direct Routing Contact Center Solution
  • A Dynamic 911 ESRP

Since the SBCs were in an HA pair, the decision was made to aggregate two (2) ports for the HA system and use single ports for the trusted network and the four (4) untrusted networks. The logic behind this decision was that because the SBCs were paired, each network has two (2) resilient ports. The client felt that they could abandon the aggregation for the other networks on the SBCs since they were setup as an HA pair:

  • The SIP Trunk provider installed their own SBCs on the client’s premises.
    • The IP address of the SIP Trunk interface on the SBC was determined/provided by the SIP Trunk vendor.
    • A dedicated circuit was installed by the vendor and interfaced to their on-premises SBCs.
    • The SIP Trunk traffic is isolated between the vendor and the client’s SBCs.
  • The client provisioned three (3) different public IP addresses and three (3) different corresponding Network Address Translation (NAT) addresses for each of the remaining un-trusted networks.
  • The three (3) NATted addresses were each on separate subnets.
  • Specific rules were created on the client’s firewall for each of the non-SIP Trunk untrusted networks.

On the SBC:

  1. The physical ports were assigned to “Ethernet Groups”
    1. The last two (2) ports were assigned to the same “Ethernet Group”
    2. The “Ethernet Groups” were assigned to unique “Ethernet Devices
    3. The “Ethernet Devices” were assigned to unique “Network Interfaces”

We can use the “Topology View” on the SBC and a table to see how these objects are laid out. We can clearly see that we have physically separated the trusted from the untrusted networks and the untrusted networks from each other on the SBC:

What do you do if you do not have enough ports on your SBC?

You have a few options:

  1. Do not aggregate your ports. If you do this, you should acquire a second SBC and implement High Availability.
  2. Purchase an additional SBC.
    1. This will increase your capacity for different networks but will add complexity to your call routing.
    2. You can opt to aggregate the ports in this configuration. If you choose not to, purchase two (2) more SBCs and implement High Availability throughout.
  3. As a last resort, route traffic from more than one untrusted network on a common physical interface.
    1. This is not a perfect solution and is not recommended.
    2. If this is your only option, you must make sure that you correctly setup the SBC to provide logical separation of the untrusted network traffic on the SBC.
    3. If a SIP Trunk vendor puts their SBC on premise, you will not be able to add another untrusted network to the IP interface being used by the SIP Trunk.

Logical Separation of Untrusted Network Traffic

On the SBC:

  1. The physical ports were assigned to “Ethernet Groups”
    1. The last two (2) ports were assigned to the same “Ethernet Group”
    2. The “Ethernet Groups” were assigned to unique “Ethernet Devices
    3. The “Ethernet Devices” were assigned to unique “Network Interfaces”

We can use the “Topology View” on the SBC and a table to see how these objects are laid out. We can clearly see that we have physically separated the trusted from the untrusted networks and the untrusted networks from each other on the SBC:

Logical Separation of Trusted Network Traffic

  • Most SBCs will have only one (1) trusted network.
  • Most SBCs will more than one (1) source of SIP traffic (or entities) on the trusted network that needs to route traffic to and from the SBC.
    • SIP enabled legacy PBX. 
    • Analog Transfer Adapters (ATAs – AudioCodes MediaPacks are ATAs). 
    • SIP enabled Paging system interfaces. 
    • SIP enabled entry control systems. 
    • SIP enabled Emergency or blue phones. 
    • SIP Phones not used by Teams enabled users.
  • Most SBCs will not have enough physical ports available to support more than one (1) trusted network.


Physical separation of these various SIP requirements on the SBC in most cases will not be an option. The SBCs will usually not have enough physical ports to support several different SIP entities that need to route calls to/from the SBC from the trusted network. It might be difficult to make multiple physical connections to a single SBC from the same LAN. Generally, it will be impractical and could be impossible to effect physical separation of this traffic on your trusted network. However, you can and should implement logical separation of the traffic. 

The same customer, described previously, had a SIP enabled PBX and several AudioCodes MediaPacks that needed to route traffic to/from the SBC. The solution was to create unique sets of the Core Entities for the PBX traffic and the MediaPack traffic. These entities were all associated with the LAN IP interface. We can see these in an updated “Topology View”: 

But there is a catch!

Not a big terrible catch but something you need to be aware of:

  • You can assign the same IP Interface to more than one (1) SIP Interface.
  • You cannot use the same UDP, TCP or TLS port on more than one (1) SIP Interface associated with the same IP Interface.
  • If the PBX and MediaPacks are sending you UDP traffic, the UDP port of their SIP Interfaces must be different. 
  • The PBX and MediaPacks can listen on the same port for traffic coming from the SBC.

What about SRDs?

  • The AudioCodes Security Guidelines document, see reference below, states:
    • It is crucial to separate trusted from untrusted networks by using different SRDs, IP Groups, SIP Interfaces, and SIP Media Realms (with limited port range).
  • The SBC user manual states:
    • “Only a single SRD is required (recommended) for most deployments. Multiple SRDs are only required for multi-tenant deployments, where the physical device is “split” into multiple logical devices.” 
  • It probably would have been better to lead with what an SRD is!
  • An SRD is a logical representation of your entire SIP-based VoIP network (Layer 5) containing groups of SIP users and servers. An SRD is a container for all the configuration entities needed for call routing within the network.
  • SBCs come with a single “Default SRD.” Unless you add additional SRDs, all your SIP Interfaces, IP Groups, Proxy Sets and Classification Rules will be assigned to the default. 
  • Several years ago, it was common to setup an SBC with more than one (1) SRD. Today, it is frowned upon by AudioCodes unless your SBC is in a multi-tenant environment.

The Bottom Line on SRDs

  • eGroup | Enabling Technologies recommends that a single SRD should be used on SBCs unless they are deployed in a multi-tenant environment.
  • We do not believe that creating multiple SRDs for each trusted and untrusted network makes an SBC any more secure than a single SRD.
  • Our read of the AudioCodes documentation and discussions with various AudioCodes engineers has us believing that it is best to avoid using multiple SRDs on an SBC unless it is deployed in a multi-tenant environment.


  • AudioCodes recommends that the trusted and untrusted networks on Session Border Controllers be both physically and logically separated. 
  • They also recommend that each untrusted network be physically and logically separated.
  • AudioCodes anticipates that most SBCs will have a single trusted network. While there can be multiple different SIP entities on the trusted network, AudioCodes has not found it necessary to recommend physically separating their traffic. They also do not say that you should logically separate the entities traffic, but eGroup | Enabling Technologies does recommend logically separating the traffic of the trusted network SIP entities.
  • Besides hardening the SBC, the physical and logical separation of the networks makes it much easier to configure and troubleshoot call routing problems on the SBC. The separation usually makes it easier to quickly understand the call flow on the SBC. 

Our team is available and ready to answer any questions that you might have about SBC hardening and security as well as overall security for your enterprise. If you need help in implementing a security infrastructure for your organization, please contact us at 


AudioCodes has written documents addressing security on their Session Border Controllers and Gateways. There are versions for the 7.2 and 7.4 firmware in which they discuss the importance of setting up the SBC’s firewall rules:

The AudioCodes SBC user manuals can also be found in the Library section of the AudioCodes website.

John Miller

John Miller

Cloud Solutions Architect - eGroup | Enabling Technologies

Last updated on July 31st, 2023 at 01:03 pm