PFsense getting digital voice to work?
-
@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.
-
The phone is behind NAT so a firewall rule without a port forward isn't going to do anything.
-
@chpalmer Thanks for that reminder of the official settings!
I went back and checked my config - I had essentially copied the default settings of the Zen supplied router (FRITZ!box AV7530AX) which is preconfigured for their digital voice service to use voip2.zen.co.uk as the SIP registrar. As incoming calls come from a different server, voip.zen.co.uk, I had needed rules in place to use the Zen device (in its default settings), or the N300A configured with the same settings, when placed behind pfSense.
I have now reconfigured the N300A to connect to voip.zen.co.uk and that has allowed me to disable the port forwarding and WAN rules I had in place. The only thing I had to do was enable the static port option in the outbound NAT for the N300A.
Much cleaner, thanks again.
-
Ah, so it's registering against that server too?
-
@bigsy I could/probably be wrong but without port forwards on the WAN, I think a situation can arise where, if you reboot the router, you won't receive any incoming calls until client re-registers. With the N300's default setting, that could mean up to an hour with no incoming calls?
-
@stephenw10 said in PFsense getting digital voice to work?:
Ah, so it's registering against that server too?
Yes.
-
Hmm, I would expect the timeout to be far shorter than that. The UDP state timeouts are 60s by default. The keep-alive packets have to be more frequent than that to allow incoming SIP signals to use them.
-
@darcey Thanks, I'll keep an eye out for that, although this router is very seldom rebooted and for this particular situation a short delay before incoming calls could happen wouldn't be an issue.
The N300 is set to for registration refresh every 180s but from a pcap it looks like re-registration is taking place every 135s and a keep alive every 20s.
-
@bigsy It sounds fairly immune to that scenario then. What I notice here, with my n300 is, that after SIP registration, the only SIP traffic from the N300 are SIP OK responses to SIP OPTIONS from the server (local asterisk). This I took to be a keep-alive mechanism.
When the firewall state's lost for whatever reason, some form of SIP packet is needed from N300 to recreate the state. That didn't come until the next SIP REGISTER and my unit's was set at 3600.I have pf states set to conservative, which AIUI keeps UDP states for 900s.
Having said all that, N300 and two handsets have worked quite well for me. Android softphones are another matter!
Thanks for the discussion.
