[Freeswitch-users] Firewall mysteriously starts blocking calls to port 5060

Sun May 5 08:59:17 UTC 2019

Hi Chad

To slightly expand on Giovanni's reply your line "but UDP's fire and forget
approach seems a poor choice for this task." made me think you may be
appreciative of some of the reasons that services select particular
protocols with a specific focus on voice calling.

You have correctly identified that UDP is "fire and forget", but this does
leave a bit of an understanding of what is happening where in the system.
The better way to look at it is to think about TCP being a connection
oriented protocol (where the protocol stack establishes and maintains a
connection) where the stack promises to provide in order delivery of
packets to the application sitting up the stack. The application doesn't
need to manage packet ordering, re transmission, etc. On the other hand
with UDP the simplified protocol stack doesn't provide the guarantees above
meaning that any of these that the application wants then it needs to
handle them itself.

So when thinking about voice services customers / users often expect a
perception of immediacy from older circuit switched phone systems (or from
other experiences) and as operators of systems we often want to seem
responsive even if we have to failover to alternative routes. So for this
we can actively retry quickly with an upstream carrier (or downstream user)
and if no reply again failover quickly to another carrier / route without
having to setup and tear down all the TCP sessions (the three way handshake
to setup - and again to close down - a TCP session adds packet round trips
to every session) before sending the call request through making things
faster and more responsive.

These reasons for SIP signalling going over UDP rather than TCP is similar
but separate to why the media is usually exchanged over UDP as well.
Obviously for the media we don't fail over to other carriers. However once
a media packet doesn't reach the other side in order / in time then that
packet is usually useless to receive (so no reason to have the protocol
retransmit that packet) so using UDP makes the best sense in these
situations.

For loading a website on the internet you don't want to lose part of the
page at random, but when we don't need all the features we pick and choose
which features are needed to make the system work optimally.

Apologies if this was seen as out of place in the conversation, but I hoped
it may help you Chad understand and as something people might stumble over.
I am happy to discuss if people want to and happy to take any additions to
ensure its as clear but accurate as possible.

Regards
Alexander

Alexander Neilson
Neilson Productions Limited

alexander at neilson.net.nz
021 329 681
022 456 2326

On Sun, 5 May 2019 at 19:18, Chad Phillips <chad at apartmentlines.com> wrote:

> Thanks for the insight Giovanni, I appreciate it!
>
> On Sat, May 4, 2019 at 10:50 AM Giovanni Maruzzelli <gmaruzz at gmail.com>
> wrote:
>
>> Ahem, udp is the original and standard transport for SIP, tcp is a little
>> minority, kind of an afterthought and few providers support it
>>
>>
>>
>> On Sat, May 4, 2019, 18:51 Chad Phillips <chad at apartmentlines.com> wrote:
>>
>>> It wasn't a fail2ban issue...
>>>
>>> This particular provider says they only send SIP traffic over UDP, and I
>>> had only opened TCP traffic to port 5060 in my firewall.
>>>
>>> The part I don't understand is how I was able to receive any calls at
>>> all from them without UDP/5060 open -- it worked for hours with my new
>>> firewall config up. That's just weird...
>>>
>>> Also, can anybody explain why a provider would use UDP for SIP traffic?
>>> From my brief reading of the spec, it does seem to be a valid protocol to
>>> use, but UDP's fire and forget approach seems a poor choice for this task.
>>>
>>> On Fri, May 3, 2019 at 11:56 AM David Villasmil <
>>> david.villasmil.work at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'd say this is a question for shorewall. But since you're here, is
>>>> there maybe some flood-prevention mechanism that would block it? Did you
>>>> check shorewall's log to try and find the reason it was blocked?
>>>>
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.work at gmail.com
>>>> phone: +34669448337
>>>>
>>>>
>>>> On Fri, May 3, 2019 at 6:07 PM Chad Phillips <chad at apartmentlines.com>
>>>> wrote:
>>>>
>>>>> Recently I reconfigured my firewall (via Shorewall) to block all
>>>>> inbound traffic to port 5060, except for whitelisted IP addresses from my
>>>>> inbound DID providers. After setup, we ran tests and everything worked fine
>>>>> for all incoming calls across all providers.
>>>>>
>>>>> Then a few hours later, calls from one of our providers started being
>>>>> blocked. All calls from our other providers continued coming through fine.
>>>>> Upon restarting our firewall service, the blocked calls from the single
>>>>> provider started coming through again.
>>>>>
>>>>> Between our successful tests and the start of the issue, there were
>>>>> zero changes made to the server.
>>>>>
>>>>> So why would my firewall suddenly start blocking inbound traffic from
>>>>> a whitelisted IP that it was previously letting through??
>>>>>
>>>>>
>>>>>
>>>>> _________________________________________________________________________
>>>>>
>>>>> The FreeSWITCH project is sponsored by SignalWire
>>>>> https://signalwire.com
>>>>> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
>>>>> services.
>>>>> Build your next product on our scalable cloud platform.
>>>>>
>>>>> Join our online community to chat in real time
>>>>> https://signalwire.community
>>>>>
>>>>> Professional FreeSWITCH Services
>>>>> sales at freeswitch.com
>>>>> https://freeswitch.com
>>>>>
>>>>> Official FreeSWITCH Sites
>>>>> https://freeswitch.com/oss
>>>>> https://freeswitch.org/confluence
>>>>> https://cluecon.com
>>>>>
>>>>> FreeSWITCH-users mailing list
>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:
>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> https://freeswitch.com
>>>>
>>>>
>>>> _________________________________________________________________________
>>>>
>>>> The FreeSWITCH project is sponsored by SignalWire
>>>> https://signalwire.com
>>>> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
>>>> services.
>>>> Build your next product on our scalable cloud platform.
>>>>
>>>> Join our online community to chat in real time
>>>> https://signalwire.community
>>>>
>>>> Professional FreeSWITCH Services
>>>> sales at freeswitch.com
>>>> https://freeswitch.com
>>>>
>>>> Official FreeSWITCH Sites
>>>> https://freeswitch.com/oss
>>>> https://freeswitch.org/confluence
>>>> https://cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> https://freeswitch.com
>>>
>>> _________________________________________________________________________
>>>
>>> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
>>> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
>>> services.
>>> Build your next product on our scalable cloud platform.
>>>
>>> Join our online community to chat in real time
>>> https://signalwire.community
>>>
>>> Professional FreeSWITCH Services
>>> sales at freeswitch.com
>>> https://freeswitch.com
>>>
>>> Official FreeSWITCH Sites
>>> https://freeswitch.com/oss
>>> https://freeswitch.org/confluence
>>> https://cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> https://freeswitch.com
>>
>> _________________________________________________________________________
>>
>> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
>> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
>> services.
>> Build your next product on our scalable cloud platform.
>>
>> Join our online community to chat in real time
>> https://signalwire.community
>>
>> Professional FreeSWITCH Services
>> sales at freeswitch.com
>> https://freeswitch.com
>>
>> Official FreeSWITCH Sites
>> https://freeswitch.com/oss
>> https://freeswitch.org/confluence
>> https://cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> https://freeswitch.com
>
> _________________________________________________________________________
>
> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
> services.
> Build your next product on our scalable cloud platform.
>
> Join our online community to chat in real time
> https://signalwire.community
>
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> https://freeswitch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20190505/23c33c35/attachment-0001.html>