On Mon, Dec 10, 2012 at 9:59 AM, Steve Spencer <[email protected]> wrote: > On 12/10/2012 09:32 AM, Vick Khera wrote: >>> >>> The remote phones in question are not using NAT, but are publicly >>> >addressed. Local phones on our LAN continue to work just fine. The >>> > firewall >>> >is at the local end and sits between the cloud and the switchvox server. >>> >When you say, "going back to a static port on 5060" what do you mean? >>> >Currently, there is an alias set up for VOIP UDP ports and for VOIP TCP >>> >port. All traffic inbound is allowed to those ports if the destination >>> > is >>> >the Switchvox server. 5060 is included in the UDP ports alias. >>> > >> >> Did you configure the "NAT" option for those lines in switchvox? I don't >> have any public IP phones, just some that are at remote locations using >> IPsec VPN. I also had to tell switchvox that the other LANs were "local". >> >> With 1.x pfSense, I used the SIP proxy package. With 2.0 I do not, and it >> does still seem to work just fine. >> > I /may/ have just found my problem, though still not sure. On the old > firewall (1.2.2) I had enabled manual outbound NAT and had specified only > the LAN network in the mappings. On the new (2.2) firewall, I had left > automatic outbound NAT enabled, which generates rules for all the interfaces > except, of course, for the WAN. I may be able to fix my problem by simply > turning on manual outbound NAT and then deleting all the auto-generated > rules except the LAN interface. The Switchvox server has it's only network > (publicly addressable) so it is not necessary to NAT, I wouldn't think. > > Sound reasonable? >
Yeah if you have a public IP subnet internally, by changing your outbound NAT, you enabled NATing of that host. That will generally break your PBX because it's not expecting that. That sounds like the cause. _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
