PFsense getting digital voice to work?
-
Hmm, interesting. So some initial googling here shows it will only work with the supplied ISP router. However that's probably not the full story. Everything is just a matter of code!
But it doesn't look easy. Using a 3rd part VoIP provider would be far easier.
-
Yup further research seems to confirm that. If you're using BT residential service with Digital Voice it will only work with their supplied router. Whilst it might be technically possible to connect to it with a standard VoIP/SIP device BT at least will not give you the details required to do it.
Now you are not actually with BT so Zen may be more flexible. However the fact they are using the same name for the service implies they may have just chosen to use BT to provide that in which case.... -
@stephenw10
hello would the these settings help ?
https://www.zen.co.uk/help-support/general-sip-settings/Paul
-
Hmm, possibly, if that's what they're using for VoIP over FTTP.
However I suspect that's for their business offering and Digital Voice is different.
-
@wheelhouse20 I have Zen FTTP and their digital voice service working behind pfSense. I use a Gigaset N300A IP DECT/VoIP base station on its own VLAN and it works flawlessly with a number of Gigaset handsets. I do not use the Zen supplied Fritzbox for this.
There''s a lengthy discussion on the Think Broadband forum which starts off with this can't be done and ends with solutions. It's worth a read for some pointers and mentions alternative options to the N300A IP.
You need to ask Zen for your 'Digital Voice' password. They will give you that no problem. The N300A IP is configured with these credentials and the Zen server details.
On my Netgate 5100, I've created a port forwarding and WAN rule from the Zen VoIP IP address to the N300A for the SIP protocol (port 5060 UDP) along with firewall and NAT rules for the VoIP VLAN.
-
@bigsy Sorry to jump on this thread. Have you also forwarded the full range of RTP ports that the N300IP opens?
Reason I ask is I have the same Gigaset DECT base and, since trying to diagnose some disconnected call issues, may have ended up forwarding more ports than I need to. I do however restrict the range of allowed remote IPs to that of my SIP providers.
Could you give more detail on your nat/forwarding/firewall rules? Cheers. -
Ooo nice. Well there you go just standard SIP if you know the credentials. Choose your ISP wisely!
-
@darcey I'm only forwarding the SIP port from a single VoIP address at Zen. I have not had to forward the RTP ports but have added them to the outgoing firewall rules for the VoIP VLAN to help lock it down a bit.
-
@bigsy Thanks. I tried reading up on this but couldn't find an answer.
From your working config, it seems RTP connections are always initiated by the client (N300IP) regardless of whether the call is incoming or outgoing. Meaning, no port forward or firewall rule needed on the WAN in respect of incoming RTP.
I am wondering if the same applies when running a PBX and trunk connection to an external SIP provider.Since switching to VoIP, I played with a couple of devices (Cisco ATA and Gigaset N300) as well as asterisk.
Currently, with asterisk, I foward UDP SIP obviously. But also (a large range of) RTP ports to the PBX.
I also added static port NAT for all outgoing UDP from the PBX. This works but I'm wondering if I actually need to port forward those RTP ports with asterisk.
I'm guessing the requirements may be different, SIP client (such as N300IP) vs asterisk & PBX trunk. -
I would expect this to work like any other SIP connection. If you're just running phones behind the firewall connecting the Zens PBX you shouldn't need anything forwarded.
If you're running a PBX then you would need traffic forwarded to it.
-
@bigsy Jumping in on this thread as I've just had DV activated on Zen Internet and am also using a N300IP behind a pfSense firewall.
I can make calls without problems, but I'm unable to receive incoming calls. When someone dials my number it cuts off straight away without even ringing either at my end or at the caller's end.
I've created:
-
a NAT port forward from any source address port tcp/udp 5060 on my WAN to port 5060 on the internal IP of my N300IP,
-
inbound rules allowing all udp traffic from 62.3.88.0/28 and 62.3.88.16/28 to my WAN address
-
inbound rules from both 212.23.7.235 and 212.23.7.228 to udp 5060 on my WAN.
I've also got an outbound NAT rule for all traffic from my N300IP to use static ports
I've tested it with the Fritz!Box on the WAN and that works for outbound and inbound calls, so Zen won't support me any further.
Could anyone give me any pointers on what to look at next?
-
-
@Bertha73 Does your inbound WAN rule allow traffic from voip.zen.co.uk UDP 5060 to destination internal IP of the N300IP UDP 5060? This is different from the WAN settings at this link if you were following them.
I have no inbound rules for the RTP traffic.
My port forward is from voip.zen.co.uk UDP 5060 to the internal IP N300IP UDP 5060.
-
Hmm, you really shouldn't need anything just for internal phones. The phone should open an outbound SIP connection to the Zen server when it registers and that should remain open. The server then uses that to send SIP signals to the phone. If that's not happening without a forward I'd check for the server using different source ports. Or for the UDP SIP states timing out.
-
@stephenw10 That was my understanding too - I have two other VOIP services (with voicehost) registered on the N300IP, neither of which require any ports forwarding or firewall rules and both work fine. I also have two VOIP services on my mobile, which work fine when I'm connected to my wifi.
I've used the Packet Monitor under Diagnostics on the firewall and can see that three INVITE packets are getting through, but there's no response. However, the same happens with the Fritz!Box when I put it behind the firewall with the same Zen telephony settings that work when it's acting as a router.
There is something happening on the firewall that is causing the response from the VOIP device to the INVITE to be dropped.
-
VoIP can be a difficult beast. Even today it hates NAT. And there are many weird and wonderful variations.
The first thing I would do is add a manual outbound NAT rule for the SIP traffic with static ports set so the remote server sees the source port as 5060.
-
@Bertha73 Is the N300 sending your WAN IP in SIP messages? There's an options on it to enable STUN so that it can discover the WAN IP.
I can't remember if I enabled this myself and currently cannot check as I have the N300 registering to a local asterisk instance.
Also are you sure the firewall is allowing RTP traffic egress from the N300/network? -
@Bertha73 said in PFsense getting digital voice to work?:
There is something happening on the firewall that is causing the response from the VOIP device to the INVITE to be dropped.
In that case, turn on logging temporarily for the default drop rule or create an explicit rule to drop and log traffic for the relevant firewall interface and/or N300 IP address.
-
@stephenw10 said in PFsense getting digital voice to work?:
Hmm, you really shouldn't need anything just for internal phones. The phone should open an outbound SIP connection to the Zen server when it registers and that should remain open. The server then uses that to send SIP signals to the phone. If that's not happening without a forward I'd check for the server using different source ports. Or for the UDP SIP states timing out.
Zen uses a different server address (voip.zen....) for incoming calls vs outgoing calls/registration (voip2.zen...).
-
Zen uses a different server address (voip.zen....) for incoming calls vs outgoing calls/registration (voip2.zen...
Voip.zen.co.uk resolves here to 212.23.7.228
Don't port forward anything but-
Create an incoming firewall rule on your WAN from 212.23.7.228 to the LAN address your sip device(s) reside at. Use whatever SIP ports that your service and devices use.
I can provide some screenshots if you need.
What RTP ports does your system use? They will most likely be different. Make the same kind of rules for those as well. Make a couple of phone calls and look at your states tab. Search for your client device IP address and take a screenshot of all its connections during that call for reference.
Alternatively use the SIProxd package. In that case you would forward these rules to your WAN address.
-
Actually this page has all the IPs you need.
https://www.zen.co.uk/help-support/general-sip-settings/
Look at firewall settings. They already know this will be an issue with real firewall devices.
Once again.. you do not need to port forward. The server will find you.
