Voice over IP (VOIP) services are changing router design.
-
Allot of the old DSLreports guys have ended up here.. https://broadbandbulletin.com/t/voip-tech-chat
Good source for related tech chat as well.
-
Thanks for replies. I'm in UK where VOIP services are replacing BT copper lines. I run my VOIP service on its own NIC interface, subnet and rules blocking cross access to LAN. But somethings still concern me. My VOIP service provider and others is recommending access to 4 IP addresses and loads of RTP ports open 'For their future service changes'. That didn't sound good for security? I'm looking further into digital call management features now built into their some routers. You access them through the router GUI making it easy to manage call lists, rather than slowly poking in numbers on phone handsets. They also seem to include latest spec. wireless and connections to smartphones. I'm not running a local business or PBX, but call features and blocking are important to my household who want their own address lists and personalised ring tones.
-
@voxmagna1 Whilst you can set up your own pbx server to use whatever limited RTP port range you wish, you will have to allow a much larger range from your trunk provider. In my case (Andrews and Arnold in the UK), that's the full range of non-privileged ports. I'm however able to lock it down by restricting the IPs. If I understand SIP/RTP at all, it's understandable they would need me to accept RTP over a larger range as they will be managing a large number of simultaneous calls.
-
There is absolutely NO reason to open up ANYTHING to the internet for internal sip clients to work with voip service.
pfsense handles this nicely keeping udp states open.
Port forwarding udp 5060 and the huge ranges that rtp dictates is ONLY needed if you run a sip server behind nat. Running freepbx localy is not considered running a sip server
unless you have remote users connecting over public Internet (and not vpn).All other issues can be resolved either by just clearing states (when debugging) or making registrations more often (like every 30 secs for stringy providers.
I have also found no use for siproxd.
As documentation says
Unless the remote PBX is absolutely strict about the 5060 source port requirement for each phone, this package is not needed.
Which is WAY deprecated too.
Change provider if they insist on such things. They are outdated for sure in many many other aspects. -
@netblues I just revisited my fw/nat rules and my description above was not wholly accurate.
For the WAN, I port forward UDP 5060 and (a limited) RTP port range inline with what I've configured in my local FreePBX (rather than the provider's).
IIRC the single trunk I set up does not register with the VOIP provider and I came to the (possibly wrong) conclusion I needed to port forward both SIP and RTP in order to accept calls. No remote users, other than VPN. I arrived at the firewall rules after incrementally testing, so don't think any are unnecessary but may well be wrong.
WRT to the provider's large RTP port range I referred to, that's UDP destination ports originating from the VOIP vlan (rather than the WAN interface). -
@darcey said in Voice over IP (VOIP) services are changing router design.:
IIRC the single trunk I set up does not register with the VOIP provider
Are you sure about that? Then how does the provider know your (possibly dynamic) ip?
no-ip hosts?@darcey said in Voice over IP (VOIP) services are changing router design.:
that's UDP destination ports originating from the VOIP vlan (rather than the WAN interface).
Essentialy this is just nat configuration and outbound rules for voip vlan, which is typically allowed by default, (unless of course you are running a high maintenance environment, opening outbound access as needed.
-
@netblues I suppose I am running a high maintenance environment. I only open up what's needed (or try to!).
Yes, I have a static IP and have gone with the provider's option 'to your server via SIP'. My reasoning being, it seemed appropriate at the time as I was also setting up a FreePBX instance.
Seems, then, this may be unnecessary as I could/should configure my FreePBX trunk as a SIP client.
-
@darcey
That is also an option that DOES require portforwarding just 5060 ONLY from your providers ip's, which is ok.
Taking this to the next level, and since this is udp, it could be spoofed and reach freepbx, in an effort to create denial of service.
I doubt you will ever be a target, but if you can avoid it then why not?(especially for someone that goes the extra mile to open up ports as needed ) :)
-
@netblues said in Voice over IP (VOIP) services are changing router design.:
@darcey
That is also an option that DOES require portforwarding just 5060 ONLY from your providers ip's, which is ok.
Taking this to the next level, and since this is udp, it could be spoofed and reach freepbx, in an effort to create denial of service.
I doubt you will ever be a target, but if you can avoid it then why not?(especially for someone that goes the extra mile to open up ports as needed ) :)
Right! Thanks. I am going to look at it again and see if I can close some more ports ;-)
-
@darcey That's my provider and I won't be generating simultaneous calls. The rest of this thread is interesting since I would rather enable the fewest number of ports. I'm not clear whether when allowed they are always open, or what in the SIP system opens them when a call is made or received. A&A have 4 IP V4 addresses. If I replace their service name with just one of their IP addresses, I can still make and receive calls on one phone, although the second IP could be used for fallback.
I have also found no use for siproxd. I couldn't install it on Pfsense V2.6, but could on V2.77. Then decided it was yet another package that needed to be kept in sync with updates and used outbound rules instead. How much damage can hackers do via UDP only ports?
-
@voxmagna1
My understanding, more so having considered this thread is, if you re-register your client with the SIP provider's server well within the state retention of the firewall, you don't need to explicitly open any WAN ports.
The incoming SIP requests are allowed because of firewall state and the RTP connections will be initiated by you, rather than the provider, based on info sent in the SIP requests.
Because I went the server configuration from the outset, I had to open ports.
I used the A&A wiki for both freepbx trunk config and IP ranges. Also, according to the wiki, there may be more than 4 SIP servers.
I don't think the RTP ports are permanently listening, only opened as necessary as calls progress.
But all that is mute if you can setup your VOIP client and stateful firewall with the appropriate re-register interval and state timeouts.
In my first reply, I think I forgot much of what I learnt in the process of setting things up. So may have complicated things! -
@darcey said in Voice over IP (VOIP) services are changing router design.:
if you can setup your VOIP client and stateful firewall with the appropriate re-register interval and state timeouts.
Yes, this is the recommended approach, security wise.
No port forwards whatsoever. -
@darcey said in Voice over IP (VOIP) services are changing router design.:
In my first reply, I think I forgot much of what I learnt in the process of setting things up. So may have complicated things!
I'm forgetting a week after getting it to work! But I'll go back to revisit re-register intervals and state timeouts. Perhaps I misunderstood that when sitting behind a non static public IP, I had to configure VOIP traffic for NAT traversal?
-
@voxmagna1 Something else that may help: Firewall Optimization Options
