If the phones don't work over the VPN, and, the VPN is allow all, its
unlikely to be pfSense. However SIP is tricky, in that as a protocol is
has very limited support for NAT. PfSense doesn't have a SIP
application layer gateway so we don't modify the settings.
However some SIP devices try to be smart, and have a "NAT" setting on
them. Some might even try to use STUN/TURN/etc to discover their
external IP.
SIP supports a VIA header which can be a public IP, or a private IP,
depending on how you connect. Your phone system will have this feature
as well. Asterisk's based products (Switchvox,etc) have a "local
networks" setting that is basically a do not nat, feature, which needs
to be turned
on (all your vpn networks will be "local" so that they are not NATted,
(non "local" networks are consider public Internet).
And thats just SIP, you have two other protocols to worry about:
RTSP, and provisioning. I'm not aware of any devices that provision
directly over SIP, most use tftp/ftp/http to provision. A lot of devices
support
setting a dhcp server option to point to a provisioning server. Might be
better that way.
Since you don't mention the specific make/model of phone its hard to
suggest exactly what is wrong, but its probably the NAT on the switch
and phones
being mismatched.
You should be able to easily tell, by doing of packet capture of the SIP
(5060) traffic and looking at the SIP headers.
SIP itself is really only used for call setup, and presence
notification. Media transfer runs over other protocols, and provision
is phone depended.
On 6/2/2013 9:24 AM, Mark Tinka wrote:
On Sunday, June 02, 2013 04:18:33 PM Mark Tinka wrote:
Given that no NAT "needs" to take place for any traffic
moving across the VPN interface (LAN<=>VPN flow), is
there any reason to assume pfSense "could be doing
something" to SIP traffic crossing these interfaces?
Just to add, firewall rules on the VPN interface are set to
"ALLOW ALL", as this is internal infrastructure.
Firewall rules on the LAN interface drop a few ports toward
the pfSense itself (none of which are required by the hard
phones), and allow everything else.
Mark.
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
