I have an OpenVPN tunnel set up to utilize for extensions offsite. It has been tested with softphones running on computers connected to the VPN and they work fine. I want to use desk phones, connecting through pi or linux based gateways running ufw/iptables. The gateway computers connect and forward traffic per the ruleset below. I can access the web interface of the phones from inside the network with the PBX. I can ping the PBX on its LAN interface through the VPN tunnel from the phone. But the extensions do not register.
my rules
*nat
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p udp --dport 5060:5082 -j DNAT --to-destination 192.168.50.3
-A PREROUTING -p tcp --dport 10000:20000 -j DNAT --to-destination 192.168.50.3
-A PREROUTING -p udp --dport 80 -j DNAT --to-destination 192.168.50.3
-A POSTROUTING -s 192.168.50.0/24 -j MASQUERADE
donāt delete the āCOMMITā line or these rules wonāt be processed
RTP uses UDP, not TCP, so itās UDP ports 10000-20000 that would have to be forwarded. However, that doesnāt explain your problem; registration does not depend on RTP at all. I suspect that the DNAT setup is insufficient to handle traffic originated by the phones (such as registration), but donāt know the details. You can troubleshoot by running tcpdump on the gateway, capturing on all interfaces. You can see the REGISTER request coming in, the mapped request sent to the tunnel, any response from the PBX received from the tunnel, and how it is sent to the phone.
However, you seem to be attempting a very strange setup. One common way of connecting a branch office with headquarters is a site-to-site VPN. The sites use different LAN subnets. Each site routes the otherās subnet through the VPN tunnel (which uses a separate subnet). In most cases, the router/firewall at each end acts as the VPN client or server, though sometimes a separate box does the VPN. In this scheme, individual computers and phones do not require any VPN logic.
A second common approach, where the VPN is just for phones, is to run an OpenVPN server on the PBX itself, with each remote phone having its own OpenVPN client. Most modern deskphones, including Yealink, Sangoma, Polycom and Grandstream have built-in OpenVPN clients and would not require a gateway.
If for some reason you must set up a gateway, try to avoid NAT. If you have multiple phones connected via a gateway with a single tunnel address, it would take a complex port mapping setup to allow each phone to register (source port rewriting) and also allow their web interfaces to be accessed from the PBX LAN.
To be clear, this is a site to site VPN doing everything you described, exceptā¦ there is only a single extension offsite, and the Pi computer is the client, not the phone. The traffic to/from the phone is to travel over the tunnel established on the Pi. Iāll try using tcdump, as you suggest.
If thereās only a single extension offsite, why not do a phone to PBX VPN with the built in OpenVPN server on FreePBX? Or have the phone connect with TLS?
The only issue Iāve found with phones connecting directly to the OpenVPN server on the PBX is every 2 years or so when you have to renew the certificate itās a PITA if you have a lot of extensions connecting that way. You have to re-configure them with so they get the proper OpenVPN Config with the new certificate info.
Iām doing all new remote phones with TLS and havenāt had an issue.
The attraction for the current approach is based on my experience with OpenVPN and established infrastructure that must already be maintained, versus adding another piece. That, and the need to upgrade the PBX too, which is still version 12.
well if youāre on 12 your options are indeed limited. I would get that up to current versions before anything else, if for security reasons if nothing elseā¦ 12 is ancient history. But I understand these situations are not always straight forward.
That said, once thatās done Iād suggest just getting that extension (and probably all of them) on TLS.
I wouldnāt see it as āadding another pieceā as much as simplifying the architecture.
I ran tcpdump on the pi and monitored tun0 to the PBX host. I had to set transport to the SIP host to TCP in order to get any traffic heading that way on register attempts. I set the extension also to TCP to match. Register still failed. Giving this up.
