A frequent topic when I’m discussion SBC configuration for Teams with customers, is where the outside interface of the SBC should be located: the LAN, a DMZ, or “live” on the Internet. All of these options can work, so let’s take a look at the requirements and benefits of each.

The LAN

Having the external interface of your SBC on your LAN can work, with a few important requirements. First, your physical external interface can’t be on the same subnet/vlan as your internal interface. This’ll cause all kinds of issues with traffic getting to the wrong place. You can have your logical internal and logical external interfaces share the same physical interface. You’ll need to also configure port ranges for signaling and media,  so there is some extra work. I don’t generally see this configuration for Teams, but do see it sometimes for Skype for Business server deployments where SfB is connecting to a PBX, or possible a telco via MPLS. Note that you can’t use one logical interface that is NATd sometimes and not NATd others – the SBC needs to insert your NATd IP into SIP packets, so you either NAT or you don’t, per logical interface. This configuration takes a lot of additional configuration, and it’s easy to mess up. I don’t recommend it if you can avoid it.

The DMZ/an “outside” subnet

This configuration involves having your Internal interface for connections to an existing PBX, and a second physical interface for connecting to Teams. This “outside” interface can be a VLAN or a firewall DMZ, anything that keeps it separate from internal traffic. Generally, the security guys insist on this being a DMZ connection and not a VLAN. You’ll need to setup 1:1 NAT on the firewall, or route public IPs into your environment for the SBC interface.

Another important step that’s regularly missed, is to disable any HTTP/HTTPS inspection, SIP helpers, SIP ALGs (Application Layer Gateways) or anything else that sounds, looks or smells like it wants to try and do something with the traffic. If your connection isn’t working, this is one of the first things that I would check. Fortinet, Cisco, Palo Alto, Juniper, all have these bits that need to be shut off. They simply don’t understand what the traffic is, and break it.

Live on the Internet

GASP! Who would ever connect an SBC live to the Internet? Well, lots of people. This is the simplest configuration that you can do. It doesn’t suffer from latency or HTTP/HTTPS/SIP “helpers”, firewall misconfigurations, or NAT issues. For those that say “it’s not secure”, well it sure is! Remember that an SBC is essentially a SIP firewall. It knows more about, and can do more things for SIP, than any general purpose/next generation firewall. SBCs typically include intrusion detection functions specific to SIP, and have robust host firewalls. Nobody is going to connect to the outside interface of your SBC on SSH, because you wouldn’t have it configured to do that, so there’s no need for a general purpose firewall to block SSH traffic. Okay, I picked on SSH here, but really, any port or protocol that aren’t SIP related.
It’s possible that your SBC will only be talking to a select few IPs (like an MS Teams configuration without Media Bypass), meaning that traffic from ANY other IP is simply dropped. While it’s possible that you’ll need to open things up – say if you turn on Media Bypass – the SBC is still going to inspect that traffic and ensure it’s valid. Again,  it’s a SIP firewall.

Conclusion

While the “Live on the Internet” configuration is a safe configuration with low administrative overhead, many security departments at organizations don’t understand enough about SBCs to understand that they are secure without a general purpose firewall in front of them. Typically this is a hill that I don’t want to die on, so I agree to having the SBC behind a firewall.

As much as possible, I avoid the one-interface solution “on the LAN” It requires more administrative effort, and is more confusion when you’re troubleshooting.