Vtech voip phone doesn't work with pfsense
-
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.
