Session Border Controller - SBCE Public IP Address Requirement Question

[JSurfer]

All the documentation I see regarding the SBC when used for SIP trunking and Remote Worker shows it requires 3 public IP addresses. Can anyone with experience implementing an SBC with those requirements confirm it has to have 3 public IP addresses? If you put a router/firewall in front of it I guess you could get it down to 2 Public IP addresses, but just seems kind of ridiculous. Without an SBC and with a router/firewall you can do it all with one Public IP address by port forwarding and separate external FQDN's (one for IPO and one for One-X).

 

[janni78]

Which documentation says it needs 3 public IPs?

You have external, internal and management interface.

"Trying is the first step to failure..." - Homer

 

[JSurfer]

Application notes for configuring remote worker with a sip trunk. It shows in the first diagram (figure 1) and talks about it through the notes. Just wanted real world feed back on if this is what it actually takes based on install experience or if there was another way around this. I assume it is required because of how the SBC applies profiles for different types of traffic/use.

http://www.devconnectprogram.com/fileMedia/download/078b0088-8b61-4d46-99fa-106db843ae8a

 

[JSurfer]

Anyone? Anyone?

 

[Pepp77]

The SBC doesnt even need a single public IP address. The only one I had uses 3 internal IP addresses. 2 on the same network for external and internal and then a single one on a second network for the management.

| ACSS SME |

 

[JSurfer]

Sounds like you deployed what Avaya refers to as the "one-wire deployment, also referred to as the screened subnet". So you had a firewall in front of your SBC, which means you have to sell the customer a firewall in addition to the SBC if they do not already have one. I guess if you created an acl/rule in a firewall (in front of the SBC, two-wire deployment) specific to the SIP providers public address(assuming they didn't have their own equipment onsite), you could separate the sip trunk signaling/media traffic from the remote worker signaling/media traffic and get away with just one public IP dedicated for the SBC/IPO.

 

[jhengel]

When we deploy SBC's we (Generally speaking because all customers are different) send all TCP/data traffic through customer prem firewall (XMPP, etc), and have UDP/Voice traffic (SIP) traverse through the SBC. SBC gets a single public IP address on the outside facing interface (not behind a firewall), and then two internal IP's (one attached to the IPO subnet and one attached to the management vlan behind the customer prem firewall). Is there something I missed that this setup would not work for?

 

[JSurfer]

jhengel,

Being the first Avaya SBC I will be installing (normally we just use firewalls..Cisco ASA's etc..)I am just looking at the application notes I posted a link to up above. And in the application notes it shows for remote worker + sip trunk you have to have 3 IP addresses/virtual interfaces defined on the B1 interface (whether those are private because their behind a firewall or 3 public because their touching the internet directly(no firewall)).

But that is why I was asking for real world scenarios and confirmation. So I get that you are bypassing the SBC with your XMPP(One-X) traffic, but how are you splitting the SIP traffic for the remote worker and a SIP trunk if only 1 IP address configured on B1? Or are you not using the mobile sip client and an external SIP provider, so you don't have to worry about splitting the two different types of SIP traffic to the B1 physical interface on the SBC as shown in the application notes.

Based off the application notes it looks like you have to configure profiles on the SBC differently for a SIP trunk versus a SIP client (remote worker mobile app) and maybe that's why they have multiple virtual IP's on the B1 Interface? Or maybe that's just Avaya showing a best practice? Thanks for the response, that is what I am trying to sort out.

 

[derfloh]

I have not that much experience with SBCs but it should a) not be necessary to let the SIP provider connect to you public IP but connect just outbound and b) if it has to be possible that the provider connects directly to you SBC the SBC should be able to route the different connections based on the used SIP domain with only one public IP.

B) is one of the points why you can get advantages if you use a SBC. It is more than port forwarding as it is done by a firewall because you can define far more rules based on SIP parameters to route or change packets.