IPFW should udp/5060 be open? (SIP best practices)

[PMc]

Hi all,

got my phone line changed to VoIP. Now I have attached an IP-telephone to the LAN, and it seems to work. But when a call is incoming, it appears as such:
> 22:16:04.689862 IP {provider-ip}.sip > {my-ip}.sip: SIP: INVITE ...

That means, there is traffic initiated from outside onto my port udp/5060. Which means, that port should be open in the firewall. But it is worse, because {provider-ip} is not well-defined: it is a bunch of dynamic aliases and resolves to something different depending on which DNS is used, so that is rather unuseable to specify in a firewall rule, and it would be necessary to open this port to everybody. And I don't like that.

net.inet.ip.fw.dyn_udp_lifetime is by default 10 seconds. I could configure very frequent keepalive packets to hold the firewall open, but that would create useless network traffic. Or I could increase that config value, but that would then concern all services, not only SIP.

So, question is: what is common best practice to handle this?

 

[sko]

Usually your device should register at your phone ISP (Registrar) via port 5060; eventually with the help of STUN to traverse NAT; and keep this channel open - thats what the keepalives are for (usually an OPTION sequence is sent for that).
Over this channel (initiated by your endpoint!) the signaling is done. Registration is always done from an endpoint to the SIP provider, never the other way around; so there is no need to open that port from the outside. If the channel is open (REGISTER -> keepalive via OPTION), incoming calls are signaled through that channel.

Our only outgoing PF rule for our phone system is this single line:

voip_ports              = "{ 5004, 5060, 3478, 3479, 7070:7089, 15000:31001, 40000:41000 }"

pass quick      proto { tcp, udp }      from { ($tel_if), $tk, ($vpn2_if) }                 to $sipgate_hosts                       port $voip_ports            tag EGRESS

Essentially all ports except 5060 may vary and have to be requested from the provider if they don't communicate them on their websites; also they may differ between "normal" endpoint-VoIP and trunking.
Our phone system spans over multiple branches via VPN, needs STUN and uses a mix of trunks and endpoints; hence the multiple source nets and port ranges. A simple home configuration usually needs fewer ports.

A proper SIP provider should have well-defined IPs and port ranges - dynamic and constantly changing IPs for signaling _will_ cause problems. I'd rather change the provider than trying to deal with such a hairy setup...
E.g. sipgate is providing the IPs and port ranges in their FAQ: https://basichelp.sipgate.co.uk/hc/en-gb/articles/204238021-Security-Settings-sipgate-IP-Port-Ranges
I'm using a cronjob to run a simple script that checks this page daily and basically only greps for the networks and port ranges set in the PF config.

 

[PMc]

Thank You, this makes things clear.

Usually your device should register at your phone ISP (Registrar) via port 5060; eventually with the help of STUN to traverse NAT; and keep this channel open - thats what the keepalives are for (usually an OPTION sequence is sent for that).

I have a configuration item in the phone to configure this manually; it defaults to 30 seconds, but can be set to any value.

Over this channel (initiated by your endpoint!) the signaling is done. Registration is always done from an endpoint to the SIP provider, never the other way around; so there is no need to open that port from the outside. If the channel is open (REGISTER -> keepalive via OPTION), incoming calls are signaled through that channel.

This all happens in the way You describe it. Incoming calls are also properly received. But as the keepalive packets are sent every 30 seconds, and the ipfw keepalive is 10 seconds (and I didn't change these defaults yet), there is a 20 second window during which packets are dropped, and the incoming call signalling happens to be delayed.

According to Your explanation, I will make these values meet. I wanted to clarify the common practice, before I increase network traffic.

A proper SIP provider should have well-defined IPs and port ranges - dynamic and constantly changing IPs for signaling _will_ cause problems. I'd rather change the provider than trying to deal with such a hairy setup...
E.g. sipgate is providing the IPs and port ranges in their FAQ: https://basichelp.sipgate.co.uk/hc/en-gb/articles/204238021-Security-Settings-sipgate-IP-Port-Ranges

https://basichelp.sipgate.co.uk/hc/en-gb/articles/204238021-Security-Settings-sipgate-IP-Port-Ranges

There is occasional discussion amongst the users of the provider about exactly this matter, and their argueing is that only the DNS name of the SIP server is well defined; the IP may change due to load-sharing or regionality aspects.
Then there are at least four ways to do DNS:
* use their public DNS
* use the DNS they communicate during DSL/PPPoE linkup (that's probably what they expect)
* use the root servers with local DNS
* use AXFR root with local DNS,
and I am not so much surprized that the results are different. I don't think they are "constantly changing", only that they can change. And they do change during system startup, because I can switch to local DNS only after that is up and running.

Anyway, it feels good not to be alone with such considerations. Thanks again!

 

[sko]

I have a configuration item in the phone to configure this manually; it defaults to 30 seconds, but can be set to any value.

This all happens in the way You describe it. Incoming calls are also properly received. But as the keepalive packets are sent every 30 seconds, and the ipfw keepalive is 10 seconds (and I didn't change these defaults yet), there is a 20 second window during which packets are dropped, and the incoming call signalling happens to be delayed.

Either increase the ipfw window size or decrease the keepalive interval - both are viable solutions. Key factors for the decision would be available bandwidth and available hardware resources at the gateway/firewall system.

There is occasional discussion amongst the users of the provider about exactly this matter, and their argueing is that only the DNS name of the SIP server is well defined; the IP may change due to load-sharing or regionality aspects.

So you are using the VoIP service of your ISP. Especially with big ISPs those are by far the worst and most broken VoIP/SIP implementations on this planet, because most big ISPs usually try to impose artificial limits on standard SIP features to sell them as "business features" and mostly break a lot of other things in the process....
My recommendation after dealing with some ISPs here in Germany (Telekom, Vodafone, o2): avoid them like the plague; use a proper SIP provider that just sticks to a standard SIP implementation, it will save you a lot of time and keeps your liver healthy.

* use their public DNS
* use the DNS they communicate during DSL/PPPoE linkup (that's probably what they expect)

If absolutely necessary I'd only use their DNS to resolve the name of their SIP/STUN servers.

* use the root servers with local DNS

This is very bad behaviour. Root servers should only be queried by other DNS servers, not by resolvers and definitely not by clients. Use one of the publicly available DNS Servers e.g. from the OpenNIC project [1] or another organization you may trust enough.


Anyhow, to address your current problem you might just have to allow your VoIP phone to connect to "any" address on the specified ports if you want/have to stay with this ISP for VoIP. It is an outgoing rule, so the only critical point is your VoIP phone - put it in its own VLAN if you don't trust it. Using a dedicated Voice-VLAN is very common anyways, especially because it makes it much easier to prioritize the traffic for reduced latency (-> QoS).

You *could* periodically resolve the hostname and update the firewall rules with a script, but from my experience this is a can of worms you better leave unopened; especially if it comes to VoIP. SIP is mostly stateless-ish and its behaviour in a lot of situations is highly "surprising" (not to say plain out stupid) and completely counter-intuitive to most/all other protocols. I.e. SIP doesn't consider a connection as lost/interrupted if you kill all states at the firewall and suddenly the "via" IPs in the headers of the keepalive responses completely change due to an internet connection failover/reconnect. It will just sit there until the REGISTER-intervall is expired...
So if this ISP really changes your designated SIP/STUN server on a regular basis, you'd also have to reduce the REGISTER interval to minimize the time your SIP-channel is dead. Annoyingly most consumer-grade ISPs have insanely high intervals (I've seen 30min!) and will completely block your registrations for several hours if you register at shorter intervals.

 

[PMc]

Either increase the ipfw window size or decrease the keepalive interval - both are viable solutions. Key factors for the decision would be available bandwidth and available hardware resources at the gateway/firewall system.

Okay, both is not an issue.

So you are using the VoIP service of your ISP. Especially with big ISPs those are by far the worst and most broken VoIP/SIP implementations on this planet, because most big ISPs usually try to impose artificial limits on standard SIP features to sell them as "business features" and mostly break a lot of other things in the process....

*laugh* that figures...
But it's actually they (Telekom) forced me to change my hardwired phone-line to VoIP if I want more internet bandwidth. I was not eager to do that. Basically I loose the modem dial-in onto my server, and I expect some extra fun getting a fax to work.

* use the root servers with local DNS

This is very bad behaviour. Root servers should only be queried by other DNS servers, not by resolvers and definitely not by clients.

No, when I say "local DNS", it means: run a named for the local site, with "root hints mechanism" as described in named.conf. (But I am using the other scheme, that is called slaving the root zones.) Maybe that is a bit much for a simple homeoffice, but I have a second, provider-independent static IP, and I think that's reason enough to also have a provider-independent DNS.

Anyhow, to address your current problem you might just have to allow your VoIP phone to connect to "any" address on the specified ports if you want/have to stay with this ISP for VoIP.

Yes, thats what I'm doing right now. Originate outgoing is not a big issue - and this will be occasionally improved.

It is an outgoing rule, so the only critical point is your VoIP phone - put it in its own VLAN if you don't trust it.

It cannot do much bad to my network. But it can dial costly numbers, if somebody hijacks it's firmware. (Or anybody who is allowed to use my LAN/WLAN/VPN could now do so. These all are things that have to be considered.)
The final idea is to have the router/gateway machine act as a kind of proxy or relay, protected against inside and outside, and only from there to have outgoing SIP connections allowed.

You *could* periodically resolve the hostname and update the firewall rules with a script, but from my experience this is a can of worms you better leave unopened; especially if it comes to VoIP.

I was thinking about doing exactly that. Good to know there will be more gotchas in the pipeline.

 

[sko]

But it's actually they (Telekom) forced me to change my hardwired phone-line to VoIP if I want more internet bandwidth. I was not eager to do that. Basically I loose the modem dial-in onto my server, and I expect some extra fun getting a fax to work.

Yes, we were in that boat too about 2 years ago when they started to terminate all ISDN accounts here and their VDSL Network was far from what you could call stable, let alone their VoIP services...
After nearly 3 months of struggle and an endless number of tickets with their (useless) tech support we transferred all our Telekom numbers to sipgate because the Telekom VoIP (esp. for consumer/end-user contracts) was and still is pretty much useless and hugely error-prone with anything but *their* special hardware and mangled/broken SIP implementation.
I've never tried to get Fax working - for sending this is completely handled by our phone system (mitel) and incoming faxes are terminated at sipgate and forwarded as email to various recipients.

The final idea is to have the router/gateway machine act as a kind of proxy or relay, protected against inside and outside, and only from there to have outgoing SIP connections allowed.

SIProxy can indeed manage the registration and keepalive and then hands over to the phone(s) in the internal network. I've used that configuration at home back with Kabel Deutschland (now Vodafone Cable) and it "kind of worked" with some small drawbacks/caveats (e.g. sometimes had to manually re-connect when wifi connection was lost).
However, we had constant problems with our Telekom accounts and SIPproxy because Telekom mangles the via-headers and removes every hop not belonging to their networks, so every information about routing/NAT on your side is lost. SIPproxy has a module especially for the german Telekom, that tries to keep track of the sessions and reconstruct the headers, but for us it was mostly a 50/50 chance of actually ending up with a working phone call.

As said - we switched everything over to sipgate and never looked back. I've also centralized all my telephony (landline numbers and mobile) with them several years ago - every number can terminate either on my SIM card(s) or a SIP client, so it's as flexible as it should be nowadays without artificial restrictions and it "just works"™ (and their support is amazingly fast and professional!)


(disclaimer: I'm in no way affiliated to sipgate)

 

[PMc]

Hi sko,
so You are one of these business shops whom they practically sent to hell by terminating ISDN? Too bad, but then its indeed the only solution to look for a better provider.
I for my part cannot say they're bad - they have a horribly useless customer support, but they seem to still have some really good engineers in their backoffice, and my connections did always work flawlessly.

Even now I do find defects elsewhere, but Telekom seems to get along with them.
I didn't look at SIProxy yet (probaply I will need that, too) but yesterday I took a look into asterisk to see what that beast can do. So, I installed an asterisk on my desktop for testing, and configured a second account in the IP-phone to register on the asterisk (same subnet - should be piece-of-cake), while the first account still works as my regular phone-line. The phone does register on the asterisk, the phone can place a call there, the call gets answered, the phone sends RTP data to the asterisk, but asterisk does not send any RTP data to the phone.

It took me a while to figure what has happened: actually asterisk does send the RTP data, but not to the phone. It sends it to my outbound dynamic IP address (which is nowhere configured, as it can change).
So, what happens: for the first account the phone asks the Telekom STUN server, and gets that outbound address told (which is actually the phone's IP address seen from public internet). And then it announces that same IP address for data transfers in the second account as well: It supports two SIP accounts, but only one RTP module.
So I tried to switch off the STUN alltogether, and surprise: Telekom still works!

However, we had constant problems with our Telekom accounts and SIPproxy because Telekom mangles the via-headers and removes every hop not belonging to their networks,

This is a two-faced medal. In my case such a behaviour makes the thing still work: they don't care about the -now bogus- SDP data in the INVITE, but send the flow simply to the IP they know. For simple situations this works around bogus configurations, but if you want to do something more complex, it gets difficult.
Probably Telekom is best for stupid consumers - which is no surprize, because most customers they have are stupid consumers. *eg*

And I once more got proof why I hate all the plastic things on sale nowadays that contain a crippled linux inside, be it phones, routers or whatever. As soon as you want to do something that is a little bit ambitioned, they fail - and there is no config file where one could fix it.