Is pfSense a SBC, or is there a package for SBC?

cdsJerry

@Derelict I'm glad to hear I'm not the only one that had a problem. I've read post from people in the FreePBX forum that had the problem too so I was pretty sure it wasn't just me.

Since remote phones need a way to reach the phone system in order to connect that has to be a port for them to use in order to establish the VPN. Sangoma phones have built in VPN but they still need the ports open.

Derelict

Yeah, phone connections over VPN are generally not an issue because there is generally no NAT in play there. The NAT that is problematic for me is between the PBX and the outside SIP trunks.

I would not recommend anyone just port forward to a PBX for inbound phone connections. Use a VPN there. You get some security and no NAT in that case.

cdsJerry

@Derelict Right. The port I had open was for the VPN to connect.

Derelict

Yeah that is completely normal.

cmhddti

@Derelict I've had this setup for more than 10 years. It's a little tricky, but not too bad. You need to forward port 5060 (or whatever port you use for SIP) from your public IP address, since the trunk provider needs to know how to initiate the session from outside, for incoming calls. You also need to reserve a small number of high ports for RTP, (I use 200 ports for ~50 users) which you can specify in the SIP settings in FreePBX, and port forward those as well. If you don’t specify the RTP ports, it'll use a random port above 1024, and you don’t want to forward that many. Finally, you need to know FreePBX knows it’s public IP address, so it can craft the SIP packets correctly. (It's usually pretty good about detecting this on its own, but make sure you put it in the SIP settings.)

Never used a SBC or any sort of SIP ALG. It's pretty solid.

Derelict

That's what I'm saying. Nothing like that has been necessary for years running a roll-my-own asterisk server to the same SIP trunk providers.

stephenw10

Even if you are port forwarding incoming connections to a PBX without NAT, which is quite common though less secure, I would not expect an SBC to be required. It may be recommended to make connections more secure but you can certainly configure a functional PBX without one. pfSense does not function as an SBC except maybe if you include the basic connectivity parts.
If you are getting call ringing but no voice or voice in one direction only that is usually a misconfigured PBX or phone sending it's internal IP to connect back to rather than a routable public IP. Of course of everything is connecting directly over a VPN that should not apply.

Steve

cdsJerry

@stephenw10 The PBX works great as long as it's not behind pfSense. I use Sangoma phones which have a built-in VPN that connects to the PBX then installs the phones settings. It allows for a plug-n-play phone that can be sent home with an employee. All they have to do is plug it in. But it won't connect if behind pfSense.

As you say it's not required, just more secure if I use a SBC to keep someone from sneaking in on SIP traffic that most firewalls don't protect from very well.

stephenw10

If it's just the VPN part that won't connect you probably need to set up some port forwards for it to reach the PBX. Like you would with any VPN server behind pfSense.

Steve

cdsJerry

@stephenw10 No. Something else happens because I still had trouble even after the phone registered. It's been months since I did it so the details have left my head. I'd have to connect it again to see what happens. I'm not sure it's worth it without SBC in place. I think I'll either leave it the way it is, or add an SBC in front of it and still bypass pfSense.

Right now this COVID-19 has me scrambling so I need to shift to priority items now and maybe come visit this again when things cool down. It seems like we're getting new updates every few hours from the state of Ohio. My wife is a teacher and I'm trying to figure out how she can do remote instruction (required to start tomorrow by her school) when we don't even have a decent Internet connection at my house. We live in the sticks and no providers. I need to look for a cellular hotspot or something.. and fast. Plus set up employees at our main office so they can work remotely. I'm scrambling. The PBX will need to wait.

stephenw10

Urgh.

Good luck. Open threads for failover WAN or VPNs or whatever you need.

Steve

totalimpact

I know its been a few months.... but thought I would chime in since someone told me I "need an sbc to do voip" - that may have been true 20 years ago, today we are blessed with a firewall that can do it right-

Create Firewall>Alias to your trunk IPs - if your trunk provider has 1 IP get a better provider. Also make alias for your PBX ip.
Go to Firewall>NAT Forward UDP 5060 to the PBX alias, restricting the source from the Trunk alias (this should keep you fairly secure)
For RTP (audio) Forward 10,000-20,000 udp to the PBX, many trunk providers may not send RTP from the same IP as the signaling, in fact they may have dozens of audio media gateways, so it may not be possible to limit source traffic there.
Then in Freepbx, (depending on your version) go to Advanced SIP Settings (may need to install this module), and make sure your local LAN subnet and public IP are entered there. Or if you have a newer version, I think its v14+, you will have to decide between Chan_SIP, or PJ_SIP driver, and adjust the advanced settings there-
https://community.freepbx.org/t/additional-sip-settings-under-freepbx-14/52782/6

If the above doesnt get you working, your provider sending TCP instead of UDP? Or you need to fix outbound NAT:

In Pf go to Firewall>NAT>Outbound, set it to Hybrid, and add a rule:
Interface: WAN
Protocol: UDP
Source: PBX alias
Dest: Any
Port or Range: Static Port checked

Flush the firewall state table, and that will probably cover everything.

NollipfSense

I used these two references to create no problems for my FreePBX ...

https://www.youtube.com/watch?v=QFk5jX-oeSo

https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-a-voip-pbx.html
The only difference I made from the above is I used a WAN floating rule.