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