SIP SDP Private IP
-
I'm having the same SIP issue as detailed in this post: https://forum.pfsense.org/index.php?topic=42503.0
Outbound NAT is assigning the correct public IP to the network layer, however, the SIP SDP data layer still contains our private IP. This will not work for our SIP trunk provider. As in the thread I linked, I confirmed that siproxd does not seem to support SIP trunks to a service provider.
What is the recommended solution to get the data layer transparently rewritten?
-
This is a good example of how SIP was not originally designed to be behind a NAT device but later adapted to do so.
Im assuming a SIP server here as you didn't mention what your trying to connect with.
Do you have more than one public IP address? In your case I would probably make use of a third interface on your pfSense box and bridge the WAN to that interface. Assign your "spare" IP address directly to your SIP server and build any firewall rules you need between the WAN and the new interface. Obviously you will have to set manual outbound NAT and leave this interface out of your NAT table.
or- did you actually get your SIP server to register with Siproxd? Can you set an "Outbound Proxy" on your device(s)?
-
Im assuming a SIP server here as you didn't mention what your trying to connect with.
Trying to connect to a SIP trunk provider with a ShoreTel virtual switch.
Assign your "spare" IP address directly to your SIP server and build any firewall rules you need between the WAN and the new interface.
Unfortunately, it seems that ShoreTel devices can only be assigned IP addresses inside the private IP space.
Can you set an "Outbound Proxy" on your device(s)?
No, ShoreTel devices do not have an "outbound proxy" setting.
-
the SIP SDP data layer still contains our private IP. This will not work for our SIP trunk provider.
Unfortunately, it seems that ShoreTel devices can only be assigned IP addresses inside the private IP space.
From these two comments it seems that without a go between these two technologies are not compatible.