On Sunday, June 02, 2013 05:29:21 PM Jeremy Porter wrote: > If the phones don't work over the VPN, and, the VPN is > allow all, its unlikely to be pfSense.
My thoughts too, especially since X-Lite works fine across this path. > 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). We tried this already and didn't have much luck. We are still playing around with it, as with you, there is little reason to believe pfSense is doing something to the traffic from the hard phone. On the other hand, the local pfSense sees traffic from the phone, but the remote one doesn't. Using X-Lite, both pfSense's see traffic. > 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. Digium initially use 5060/udp for provisioning, and them move to 5062/udp to complete it. RTP defaults to 10000/udp - 20000/udp, but we're nowhere near that stage yet. We're just trying to get provisioning and registration going. > A lot of devices support > setting a dhcp server option to point to a provisioning > server. Might be better that way. You refer to DHCP Option 66. In the case of provisioning, it simply does the same thing you're doing on the phone, i.e., telling the phone where to find a SIP server. > 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. The phones are Digium's own D40 and D70 hard phones. > You should be able to easily tell, by doing of packet > capture of the SIP (5060) traffic and looking at the SIP > headers. A packet capture on the local pfSense shows the phone sending traffic toward to the remote SIP server. The issue is that the remote pfSense never sees that traffic to hand it over to the SIP server. Again, everything looks nice and clean when using X-Lite. IP settings on the phone are very basic. We can confirm the phone get a good DHCP assignment, and it is, in fact, pingable from the remote LAN. So this looks like an issue with SIP and not IP to/from the phone. > SIP itself is really only used for call setup, and > presence notification. Media transfer runs over other > protocols, and provision is phone depended. Switchvox do things a little differently. 5062/udp is used for provisioning when running Digium's own phones. There are a bunch of other ports used for other features on Switchvox, but that's at a much higher level, and fairly specific to Switchvox. Will keep hacking it and report back for the archives. Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
