Vtech voip phone doesn't work with pfsense
-
An office needed additional phones the Vtech VSP735 is replaced with the VSP736. They already have 15 functional 735 series but the 736 will download it's config, time, and even show registered with the provider but it doesn't show registered on the phone. I know they received their config because taking the phones to an office not using pfsense enables them to fully function. I know it's not a bug with the 736 because a different office uses 8 of them with the same provider. I tried various known voip configuration changes in pfsense and none of them worked. It is a hosted PBX platform. Any suggestions where I can start troubleshooting pfsense? From day one I have state table optimization set to conservative as it was necessary.
-
The PBX is external with just phones behind the firewall? Normally no special config would be needed for that setup.
Setting conservative state timing is only required for some devices that have high keep-alive settings. However even such a device would connect initially and then fail to receive calls etc.
Do you see any blocked packets to or from the phone?
Do you have any outbound restrictions in place?
Ultimately a packet capture against the phone's IP compared to one pof the working phones should show the difference there.
Steve
-
@stephenw10 This pfsense install still isn't complete I intend on doing firewall rules in the future. Right now it's a pretty default install only thing I have setup are static DHCP pools and WAN failover. The conservative configuration was needed at multiple locations as the phones didn't work reliably until setting it. I did a packet capture and didn't see anything odd. It looked like all communication worked. At first I wanted to blame the phone until I realized it works behind other firewalls. I tried the following https://www.netgate.com/docs/pfsense/nat/configuring-nat-for-voip-phones.html but after doing all those steps it took down all the phones that were previously working and didn't make the news devices function.
-
Yes, that's not required for the vast majority of PBXs these days. Only those that would refuse SIP unless it was sourced from port 5060. But if that were the case all your phones would be failing.
Is this phone using failover WAN group? Via the same firewall rule as the other phones?
There must be something different about it. Some additional requirement it has.
Steve
-
@stephenw10 Yes sir the firewall rule for the failover applies to the entire netmask of the phone NIC. I took the phones to another office behind pfsense that doesn't have WAN failover and it still didn't work. That office uses Aastra and Vtech phones to the same hosted PBX provider and they all work. The provider has the phone pick a port that is established to combat the 5060 port issue. I'm trying to figure out where to go from here as patience for the new phones is wearing thin and I badly don't want to leave pfsense. Other firewalls tested with these phones was Zentyal and mikrotik where they successfully worked.
-
As I said if I was doing it I would get packet captures on the internal interface filtered by the phones IP, grab the registration process for both phone models and compare them. Failing that check the firewall states for those IPs, is the new phone opening states on other ports? Maybe a clue there.
Steve
-
I'm not sure how to tell where things are going wrong with the packet capture. I do see that the problematic model does get a back successfully registering it so that explains why it does show up on the PBX as being registered. All the outbound ports are open so it's not that one is trying to use blocked ports.
-
Make a WAN rule allowing your PBX server to reach your phones local address and see if that helps.
-
Okay I looked closer at the packet capture and noticed some registration requests come back 401 and sometimes 404. They also come back 200 OK so I'm not sure what is going on there. Odd thing is a reminder this phone works 100% behind 2 other types of firewalls. I don't know how to make sense of the packet capture failing behind pfsense.
As for the firewall rule that wouldn't really work because it chooses a port to communicate when the phone contacts the hosted PBX server. I could specify by IP but I don't know how that'd make a difference.
-
In my case I use a service that does SIP on their servers but then pass me off to other servers for RTP.
I build an incoming SIP rule (NO NAT) that points to each of my phones on my local interface. One phone gets a rule from the server to its LAN address.. Multiple phones get a rule pointed at their subnet. (depends on the building..) RTP gets similar rules that Ive built by watching the connections and the firewall logs during call attempts. The pic below is one from a spur office with one ATA. (Here at this location Im using SIProxd because thats how I started out but could easily do it with similar rules as Ive done at some other locations we have.)
There is no need to do static port or any port forwarding.
-
This wasn't a PBX I put in the cloud. It's a hosted PBX service just like ring central and all the others. I've been testing pfsense at a few locations to see if I want it to be my primary platform so I'll admit I have little exposure. I wish they offered a 1 time support ticket to see if we can get passed this. Your theory is to just create a blanket rule from the IP of the PBX to the subnet the phones are on? The other 15 phones are working fine with the current rules in place. It's just this new model that is giving me fits. Perhaps I'll capture a packet of the phone working behind a different firewall and compare it. Even if I have that data I won't know what it takes to remedy pfsense.
-
Im just on a cloud service as well. But yes. Blanket rule but similar to the way Ive written mine..
Some phone equipment just seems to work better than others. In your case your newer model may have a default setting that does not equal what the older models have.. There may be differences in the config your not allowed to see or change.
Perhaps though.. try a different SIP port and see if that works.. Try 5078 and see if you get a different result.
-
I'm assuming you put the blanket rule on the WAN connection since you said it's an inbound SIP rule? I just did a blanket rule to my phone subnet and it made no change in it getting registered.
-
Right.. On your WAN tab.
Id wonder then if the phone is trying to use TCP over UDP?? Or something simple like that. Do you get your phone config from an offsite TFTP server?
-
Being a cloud service as soon as you provision the phone it downloads the known working config. This is why I'm super confused this is happening. The phone gets a known working config and just works through the service with ssl and establishes a port to get through nat. 15 of the vsp735 series have been working for 3 years and now the vsp736 but it's all managed automatically by the service provider. That's why if I take the phone somewhere else that has never been configured to work with the pbx it functions. The point of a cloud pbx is the phones can roam anywhere and work.
-
Go to /system_advanced_firewall.php
Down to NAT translation:
Enable the proxy on your VOIP phone interface. See if that helps.
-
Unfortunately that didn't change anything either.
-
I believe you may have to reboot your router for that change to take.. I could be wrong.
-
Does the phone get its address from DHCP on your system or did you set it via a static address?
-
All phones are on DHCP. Most are fixed addresses in the pool. I should also mention last week I took it to another location with pfsense on a netgate device and it did the same thing. That location has about 20 phones through this same hosted pbx service. Just rebooted the router with the nat+proxy turned on and rebooted the phone it still didn't register.