We'd love to hear about it! Click here to go to the product suggestion community
We have an external network where a voip server sits on (192.168.5.0/24)
We have clients on an internal network 10.1.1.0/24
Client 1 10.1.1.1 NATs to 192.168.5.1 and so on with the other clients so that all clients appear as 192.168.5.x to the voip server on 192.168.5.250
Problem is, the voip server see's the invite coming from the original ip address and not the nat'd address which results in it being rejected.
Now turning the Voip helper on gets us a little bit nearer but according to Sophos, you shouldn't use standard NAT eg SNAT/DNAT with this.
So my question is..... how do I present the the client 10.1.1.1 as 184.108.40.206 without having a NAT in place?
I use VoIP through a UTM without any issues at all.
I always use MASQ (unless there is a specific reason the use both SNAT and DNAT rules) when going from one network (or device) to an external server.
Currently I have used both scenarios (NAT & MASQ separately) with different customers.
I also place the client/network and sever in the appropriate section within, Network Protection --> VoIP --> Sip (I am presuming you are using SIP)
I only use the VoIP Helper when I know the exact bandwidth that is supplied to the location, otherwise I have always found it gets in the way of other services.
In reply to JasonFell:
when I use a SNAT/DNAT we can't connect as it appears that the invite contains the original IP rather than the natted IP.
Looking at the Sophos article:
It says if you enable the SIP helper, you shouldn't use NAT. The it contradicts itself and mentions masquerading. Now, if you can use masquerading, you can surely use SNAT.
Enabling the Sip helper got us a little further last time so we'll do some further time limited testing.
So to confirm, you use the Sip Helper as well as NAT?
In reply to Louis-M:
I had a similar issue when I was trying to connect an obi on one vlan/subnet to a pbx on another vlan/subnet.
Solution turned out to be a setting in obi's sip properties for that particular ITSP, SymmetricRTPEnable . After checking that no issues.
Maybe your sip client has a similar option?