1

We have a gateway which faces out to our VoIP SP. As we get more users we need some security in front of it.

Currently our gateway terminates directly to the SP. We would like to put a SBC in front of it as some form of security.

  1. Is this sufficient ?

  2. can I do NAT with Cisco CUBE?

Improve this question
7
  • Why would you want to do NAT? That can break VoIP protocols, and you never want to use it unless there is a compelling reason. You probably want to use a transparent (layer-2) firewall.
    – Ron Maupin ♦
    Sep 18, 2018 at 13:56
  • I want to hide my private network topology... Cisco CUBE says it can do this, but if not by NAT, then how?
    – user10021657
    Sep 18, 2018 at 14:33
  • Firewalls are what give you security, not NAT. A transparent firewall will protect your network.
    – Ron Maupin ♦
    Sep 18, 2018 at 14:37
  • what firewall would you suggest for VoIP solutions? As anything I read up on suggests the use of an SBC over a firewall.
    – user10021657
    Sep 18, 2018 at 20:22
  • Product or resource recommendations are explicitly off-topic for SE sites, except Software Recommendations and hardwarerecs.se. Using a firewall (or SBC as a firewall) does not preclude you from doing what you suggest, but you must understand that NAT can break VoIP, requiring the use of STUN/TURN or ALGs to get around the problem. It is really just a kludge to extend the life of IPv4 until IPv6 (which has no NAT standard) can become ubiquitous.
    – Ron Maupin ♦
    Sep 18, 2018 at 21:04

1 Answer 1

Reset to default
4

From what I understood about SBCs (by virtue of providing the networks, firewalls and routing for SBC deployments), an SBC does not (need to) actually route/forward IP packets between customer and SP network. [1]

There is the customer LAN side, with an interface and IP address (and if needed routing configuration) to match the customer's environment. It will only ever exchange data (mainly some SIP dialect and RTP streams) with customer's equipment (most probably the PBX).

There is the service provider side, with an interface and IP address (and if needed routing configuration) to match the SP's network. It will only ever exchange data (mainly SIP and RTP) with the SP's network.

The SBC itself is something like a dual homed proxy host: SIP and RTP flows are terminated on one and (re)initiated from the other interface (and vice-versa), so there is no need to actually route/forward packets between customer side and SP side - hence there is no need to NAT.

Some simple interface access lists on the SP Interface, permitting relevant traffic to/from the SP side interface might be enough to completely lock it down and have your network unexposed, all without the need for and the hassle of NAT.

Optionally, you may want to consider putting the SP side interface into its own "stub VRF" (VRF with only a single interface and it's own default route). However, that would require that the SBC related config items for the SP side are (or can be made) VRF-aware.

ADDON:

Setting up an SBC will add another "application layer hop" in the Voice streams between your PBX and the SIP peer systems at your Service provider, either between yor PBX and gateway or between gateway and SP. Make sure that your networking team is comfortable with understandig how the SBC works and the accepts responsibility to maintain an integral part of the VoIP solution

[1] the key clue to this assumption: I only ever needed to establish connectivity between PBX and the LAN/customer side of the SBC. Never did I have to add any routing configuration for the SP Network (or IP addresses/ranges of their SIP service) towards the LAN/customer side of the SBC. I did ask the SBC implementators multiple times if that wasn't needed - and they kept confirming that it wasn't.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.