J179 SIP remote workers / with or without SBC? 5

[rgunther]

Hey guys - wondering if you can give me some advice on how to deploy our remote workers w/ J179 phones. We currently have 7 IP500v2 (R11.0.4) SCN all on the same local LAN in which we have workers spread all over. We would like to start deploying some remote J179 phones, but realize the need for a good firewall or SBC. Is a good properly configured firewall enough, or should we go with the ASBCE? Also can we use a single SBCE for our multiple IP500v2 setup? We do have a couple of J179s deployed now - but they are all registering to the ip500 locally and not remote; as our IP500's are not yet exposed to the public inet.

 

[Westi]

I have not touched an SBC yet for anything.
I would love to play with one but so far routers are our way to go and we usually give pointers to the IT team for the setup if there is only 1 shared Internet but if we provide the voice port we provide a firewall and keep the port forwarding to a minimum. Make sure you don't forward the Management ports of the system 5080x and maybe only forward 1000 UDP ports or less as you don't need that many.

Joe
FHandw, ACSS (SME)

Remembering intrigrant 2019

 

[derfloh]

I did several using ASBCE. A little tricky but works well.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[G van Hamburg]

I always advice to always use a SBCE! You can use one SBCE for multiple IPO’s and it will keep you in complete control of your remote workers.

Freelance Certified Avaya Aura Engineer

 

[derfloh]

But it's much easier to have multiple public IPs. One for each IPO.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[G van Hamburg]

Sure, you can provision the A1 and B1 with multiple IP’s and use a separate (public) IP for each IPO. But that’s a design decission. Why an SBCE? See the SBCE as a voice firewall. It is secure by design and opens ports you configure. It can allow/block traffic based on SIP uri’s, user agents, etc and deeply inspect SIP messages using scrubbers and policy's. But this info is all on the internet.

Freelance Certified Avaya Aura Engineer

 

[rgunther]

Thanks everyone this helps. If we decided to go with just a firewall and forward to the IPO can anyone tell me what ports will need to be forwarded?

 

[G van Hamburg]

I hope it works out for you. Ports can be found here:

https://downloads.avaya.com/css/P8/documents/101064449

Freelance Certified Avaya Aura Engineer

 

[jamie77]

Server Edition has some of the SBC security built in since 11.0.4.4, so far less argument for an SBC. I woudn't do it for an IP500 though as it doesn't have this stuff.

Adding an SBC isn't just about if it will work or not, its an added security layer to the customer network.

If its the kind of site that will happy run their network on a £100 'firewall', then they are never going to buy an SBC.



Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[janni78]

I would never recommend a customer not to have a SBC, but a poorly configured SBC isn't much better than not having it at all.

Currently it's easy to find unprotected PBXs on the internet so basic firewall protection is often enough to keep most of the attackers away, in the long run tho these will start to get exploited to a much larger extent than today.

The way remote workers are often implemented today by many isn't much better than if you would allow your users to access in-house applications by just forwarding ports to the servers that the application needs.

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

 

[G van Hamburg]

I am working on my new website / blog. When I am done I will share it. As a freelance engineer I have installed many SBCE’s even for Avaya. In my opinion, an SBC is a mandatory device for remote workers.

Freelance Certified Avaya Aura Engineer

 

[derfloh]

I agree with you GvH.

I've done a lot of SBC installations with IPO as well.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN