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.
-
What mystery PBX provider is this?
They either require:
- Static outbound NAT
- Ports forwarded in from them to the phones
Neither should be required for any cloud PBX provider that wishes to be profitable in 2018.
NAT+proxy has nothing to do with anything here. You should start by turning off everything you have tried that did not correct your problem.
Sounds like a problem with the VSP736 to me.
-
@derelict this provider doesn't require any manual work. All phones I've put at any other office have just worked because without that user friendliness they'd be toast. I immediately thought it'd be the phone until I realized I have them working at other places and as soon as I relocated these ones they worked fine. Yes, it might be a combination of problems but other routers are working. I decided if no solution is found soon I'll probably just take a residential class router to hold them over until I decide if pfsense support plans can fix this or if I go with a commercial brand. Already emailed calyptix for a quote.
-
My guess is it's something you have done to try to "fix" it that is breaking it.
There is nothing special about pfSense in this case. It does NAT just like everything else.
-
@derelict yeah I reversed all changes that were attempted and even thought perhaps I could reinstall. Then I decided before going that drastic I'd test it at another branch that had nothing tampered with and 20 phones working. That's when I concluded every variable had been exhausted and created this post.
-
Well it must be looking for something besides normal outbound NAT.
There is nothing special about pfSense here.
All your other phones are working, but not this one.
I would ask the vendors what the secret sauce this phone requires is.
Barring that I would packet capture a working phone and a non-working phone and see what the difference is. There must be one or more differences or it would also be working.
-
As posted above the non working phone gets registration 200 ok then keeps going while it swaps between 200, 401, and 404. If I'm able to plug them into a residential grade router tomorrow and they work that'll be 3 different routers they've worked behind. It's probably a combination of the phone and pfsense. I don't understand the situation and it sucks knowing I can fix it tomorrow with a different router.
-
pcaps will tell the tale.
I understand the frustration but without knowing what, specifically, this phone needs that the other phones don't it's pretty much impossible to make a recommendation.
-
I'd love to post the pcap but I know it's a security risk to throw online for the whole world. I unfortunately don't know enough to interpret what can be done to fix the errors in the capture.
-
How do these guys reach the internet?
Have you done anything to block DNS and to force the users to use pfsense as the only DNS?
How well does your "cloud" pbx provider work with you? (who are they?)
If your doing a PCap right.. the results would not have any data from any other source. If you are doing this job you should know how to scrub those anyways.. Do the PCaps and look at them yourself.
Pfsense is a stateful commercial grade router option. Its doing its job and you just have to know how to make it work. If this organization is such that you could install a over the counter solution without losing this account then there is probably nothing to worry about by sharing. Id myself be looking for a job in another field.
If you have signed a non disclosure then a little scrub goes a long way.
Its very difficult for anyone here to diagnose a problem of someone else's without speaking face to face and having access. Everyone does their best. But in this case you may have to work with the manufacturer to overcome this.
Remember..
SIP was not originally designed to be behind a NAT solution. That was built into the standard later..
Vonage was sued for patent infringement and that lawsuit set the direction of anyone else that dare open a VOIP company. Everyone does something just different enough to avoid a repeat..
Ive had some really nice looking SIP devices in my possession to alpha test. Many failed because they were to far from any standard. Almost to pretty to throw away.
-
@chpalmer They connection they use for their phones goes over a wireless dedicated broadband. DNS is forced through pfsense using cloudfare. The other day I thought of scrubbing the pcap but didn't take the time yet. I know pfsense is a mature project and I'm sure there is a fix and I'd never permanently install a garbage router but their switch for the phones is separate from the LAN so I could easily plug in a temporary solution while I wait for another router to arrive. Netgate states about a week out until I could receive their official hardware and support. I'm sorry for my ignorance with pfsense as I only recently started using it. I was enjoying Zentyal until they tanked and am seeking a new direction after considering untangle. I'd rather stick with open source. I'm not entirely pointing fingers but feel I have eliminated the majority of the possibilities for now. I appreciate you volunteering to help and the ideas you had me test before. I'm going to get a pcap tomorrow of the phone working behind an alternate router and see what the difference is than behind pfsense. If I scrub them I'll post them.
-
If you PM those captures to me I can take a look.
Mostly in a packet capture I'm looking simply for the presence of packets from a particular IP. With SIP you can look a bit deeper and see if there's anything obviously wrong.The most common cause of "but it works fine behind my other router" is that the device in question either requires a SIP ALG or is misconfigured but the SIP ALG was fixing it. pfSense does not have a SIP ALG other than SIProxd but you should avoid using that unless you really know you need it. Tha is the sort of thing that a packet capture can show you.
However phones behind a firewall with an external PBX do not normally require anything as has been said.
This other phone must be trying to do something different.
Steve
-
Keep in mind that many VOIP devices have their own DNS set in the config of the SIP section.
If you are forcing all DNS queries to the pfsense box and locking devices down from being able to query their own choice of servers that very well could be your issue.
-
@stephenw10 says I can't start a chat with you unless you initiate it.