OPNsense Forum
Archive => 19.1 Legacy Series => Topic started by: ranceh on April 12, 2019, 06:35:38 pm
-
I need some advice on how to setup opnsense to allow sip client to work correctly.
By using Wireshark I was able to determine that SIP authentication requests were being sent, but no reply was received. If I enable my full-dns work vpn then the soft phone setup works fine.
Other folks in my office have informed me that it works for them without vpn, so that suggests to me that my opnsense box is somehow blocking sip or sip replies.
Can someone explain the right setup for this? Thanks.
-
Most SIP run on UDP, so the firewall has no way of knowing where to forward replies to your packets. There are (extremely ugly) hacks to work around this, proxying the SIP packets, waiting for the stars to align etc. etc., but this are the methods that will work no matter what:
1) Forward the UDP port in use (usually 5060, since you have captures, you know the port already) from the office to the client (important, don't leave it wide open) to the client (softphone in your case) from the WAN. Not usually recommended, depends on your threat assessment (ie if the phone is on a separate VLAN, not talking to anything else, there isn't too much harm in going this route). Here be dragons.
2) Get a PBX system and use *that* to connect to the remote office then your softphone to that. Usually PBX systems are (supposedly) kept up to date. Can get pricey, depending on what you are doing and you still have to figure out how to actually get it connected through another option.
3) Use a VPN to connect to the remote office, initiated on your opnsense. Easy, set up and forget type of thing.
4) Use a VPN on the softphone (I'm assuming softphone = SIP client on PC, otherwise on the phone) to get it directly connected to the office. Easy, set up and forget type of thing.
5) Variation of 4: Get connected through an encryption layer, they use TCP to do their thing (=stateful, hence OPNsense can deal with it).
6) Use straight up TCP.
Since running authentication and calls over the public internet unencrypted isn't considered best practice these days*, I would go with either a VPN or encrypted connection to the remote office. The percentage of the remote office not knowing how to set that up are pretty high though (>99%).
* actually scratch that, running everything wide open is considered best practice judging by the clusterf***s that I see in production.