Solved FreePBX fail2ban or SIP provider whitelist on router?
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@JaredBusch said in FreePBX fail2ban or SIP provider whitelist on router?:
Twilio uses SIP registration, so you need to open nothing inbound.
So forwarding port 5060 to my PBX isn't necessary?
Nope
-
@JaredBusch Do I need to set my Registration to Send in the Trunk settings? Right now I have it at None.
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@JaredBusch Do I need to set my Registration to Send in the Trunk settings? Right now I have it at None.
That is not normal for a Twilio trunk.. If oyu have it at none, then yes, you need to have the port forwarded. Because you are using IP auth.
But that is not Twilio's recommended method.
Sec, I'll dig up their instructions. -
Here is the page with the guides: https://www.twilio.com/docs/sip-trunking/sample-configuration
Here is the guide: https://www.twilio.com/docs/documents/53/TwilioElasticSIPTrunking-FreePBX-Configuration-Guide-Version1-0-FINAL-06122018.pdf
Starting at the bottom of Page 4:
You can see here that they say to use Outbound authentication.
Because of that recommendation, you do not need to open/forward a single port in the firewall.
-
I'm not sure why it doesn't need registration. But it doesn't.
-
@JaredBusch said in FreePBX fail2ban or SIP provider whitelist on router?:
I'm not sure why it doesn't need registration. But it doesn't.
Wait, yes I am. Because these two are not behind NAT anymore.
So with you using NAT, you probably will need to send registration.
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@JaredBusch said in FreePBX fail2ban or SIP provider whitelist on router?:
Twilio uses SIP registration, so you need to open nothing inbound.
So forwarding port 5060 to my PBX isn't necessary?
That's pretty normal. Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel. So there is no need for inbound. Like VLANs for VoIP, loads of people repeat the myth of port forwarding. But it's relatively rare that you need that for the PBX, and "never" for phones themselves.
-
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@JaredBusch said in FreePBX fail2ban or SIP provider whitelist on router?:
Twilio uses SIP registration, so you need to open nothing inbound.
So forwarding port 5060 to my PBX isn't necessary?
That's pretty normal. Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel. So there is no need for inbound. Like VLANs for VoIP, loads of people repeat the myth of port forwarding. But it's relatively rare that you need that for the PBX, and "never" for phones themselves.
Port forwarding is absolutely required if you have external phones. Unless you go VPN.
Be clear on what you are stating @scottalanmiller
-
@JaredBusch said in FreePBX fail2ban or SIP provider whitelist on router?:
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@JaredBusch said in FreePBX fail2ban or SIP provider whitelist on router?:
Twilio uses SIP registration, so you need to open nothing inbound.
So forwarding port 5060 to my PBX isn't necessary?
That's pretty normal. Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel. So there is no need for inbound. Like VLANs for VoIP, loads of people repeat the myth of port forwarding. But it's relatively rare that you need that for the PBX, and "never" for phones themselves.
Port forwarding is absolutely required if you have external phones. Unless you go VPN.
Be clear on what you are stating @scottalanmiller
yeah - I was getting stumped on what exactly Scott was saying there.
-
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel.
Twilio doesn't connect to me to setup the channel when there's an incoming/originating call?
I don't see how they could ever connect to my PBX if it's behind NAT without either a VPN or the port being forwarded.
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel.
Twilio doesn't connect to me to setup the channel when there's an incoming/originating call?
I don't see how they could ever connect to my PBX if it's behind NAT without either a VPN or the port being forwarded.
That is the point of registration. The PBX sends out a registration and then maintains that port reference. Calls are sent inbound to that IP and port. Magic using standard NAT.
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel.
Twilio doesn't connect to me to setup the channel when there's an incoming/originating call?
I don't see how they could ever connect to my PBX if it's behind NAT without either a VPN or the port being forwarded.
No it doesn't. Your PBX already had an open line of communication, and that is used.
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel.
Twilio doesn't connect to me to setup the channel when there's an incoming/originating call?
I don't see how they could ever connect to my PBX if it's behind NAT without either a VPN or the port being forwarded.
No, you connect to them. The connection is always there, it doesn't get set up at the time of a call. It is a trunk. You are thinking of HTTP which sets up a new connection for every interaction. Very different.
-
SIP Registration keeps the UDP ports open only for so long (I believe the ERL defaults to 90 seconds). So long as your registrations occurs on regular intervals that are lower than the UDP timeout, your port is effectively being forwarded automatically. Some routers do this much better than others - ERLs are pretty great and we recommend them. SonicWalls are the devices that we have the biggest headache with. If you can, enable NAT timeout on the PBX and keep that frequency low - that will keep the UDP port open forever and does take care of most problems with Port Forwarding. (Though I still prefer Fort Forwarding!)
When the PBX registers to the server/carrier, it gets the public IP information from the registration request and add its it to the call routing. You have to be careful though - just because you can receive calls doesn't mean you will have audio available - those can come on different ports and from different Public IPs. Smarter routers (like the ERL) understand the context of the transmission because they understand the dual-method involved in VoIP (RTP and SIP) and can fix mistakes other routers cant.
-
Getting rid of my silly double NAT setup fixed my SIP registration with Twilio. Apparently there was a SIP ALG setting in my ISP provided modem/router, too. :man_facepalming: Not sure exactly which of the two was the culprit, but either way, both were bad.
Everything is working great again without the port forwarding.
-
@bnrstnr SIP-ALG in ISP provided gear is nearly universal.
-
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
@bnrstnr SIP-ALG in ISP provided gear is nearly universal.
Guh, who would have thought... Is SIP-ALG purely sabotage or is it useful in certain scenarios?
-
@bnrstnr said in FreePBX fail2ban or SIP provider whitelist on router?:
@scottalanmiller said in FreePBX fail2ban or SIP provider whitelist on router?:
@bnrstnr SIP-ALG in ISP provided gear is nearly universal.
Guh, who would have thought... Is SIP-ALG purely sabotage or is it useful in certain scenarios?
Actually sabotage. Ubiquiti is the only vendor that I know where it works most of the time.
Most firewall vendors are also either phone companies or in bed with phone companies and have a huge interest in convincing people that other phone products don't work reliably.
