Hello Everyone.
Ive noticed strange issue on road warrior and sip clients.
ive tested this on tun adaptor and here is what Ive found
when a sip client originates its packets the PBX inside my office LAN sees it coming form the virtual subnet.
so when the pbx send back it send back to the virtual openvpn subnet which does not seem to translate back to the actual client's ip being the rd warrior.
so for example:
RdWr ip: 192.168.5.4
logs successfully to Office LAN: 192.168.7.0/24 and initiates sip to pbx: 192.168.7.10/24
using openvpn subnet of 10.1.1.0/24 and the sip client having ip: 10.1.1.4/24
pbx tries to communicate back to ip: 10.1.1.4 but it goes no where and it does not reach the sip client causing voice to break
anyone have a clue on this pls?
The client may be registering to the PBX with their LAN IP instead of their tunnel IP. Do you use a STUN service?
FWIW, I use Grandstream Wave on Android with FreePBX using an OpenVPN client and it just works. Maybe try a different soft phone?
Bart...
no Im not using stun server.
but what I have noticed is that pbx is replying back to the private tunnel ip which is not translated back to the device ip.
I tried all other clients and same behavior
Quote from: samnet on September 18, 2023, 11:18:52 PM
replying back to the private tunnel ip which is not translated back to the device ip.
The client should hold both a LAN IP and a tunnel IP and the PBX should reply to the latter. Can you run a packet capture on OPNsense to confirm?
sorry for late reply, the issue keeps coming back. I will send you pcap file directly to you hope it helps
Quote from: bartjsmit on September 19, 2023, 07:38:21 AM
Quote from: samnet on September 18, 2023, 11:18:52 PM
replying back to the private tunnel ip which is not translated back to the device ip.
The client should hold both a LAN IP and a tunnel IP and the PBX should reply to the latter. Can you run a packet capture on OPNsense to confirm?
I've seen this sort of behavior when using Freepbx/PBXact with Endpoint Manager to configure remote SIP devices.
If this is your scenario try resetting the SIP device to factory, configure a temporary rule on the firewall to allow insecure access to the configuration address, set the SIP device provisioning to the same address and run the provisioning.
When it restarts it should bring up the VPN and then use the secure address to talk to the PBX. After which you can remove the temporary rule.