Need assistance with port mapping an internal PBX
-
Hi Everyone,
We have setup a local 3cx PBX server in our network and are unable to get the ports to mapped correctly to our SiP provider. I think the issue is that we cannot get the correct static mapping setup. The main problem is that we can receive inbound calls and audio works just fine however, if we dial out audio does not work for either party. Our 3cx Firewall checker shows that all ports cannot be reached.
This is just an example of a simple port forward I tried for 5060 -
We have tried port forwarding with the usual NAT rule with an alias of ports but the more I am reading the more it says that I shouldn't be using direct port forwarding. Instead we are supposed to use static port mapping to forward incoming traffic back out certain ports to our SIP's external IP address without changing the source port.
Does anyone have an example image on how this is done? We are using 3cx and the ports that need to be open are here - http://www.3cx.com/blog/docs/ports-used/
Do we need to do something with the NAT Outbound tab? Essentially we need some more clarification about this - http://doc.pfsense.org/index.php/VoIP_Configuration
-
I had this same problem with a cisco cme. I even worked with a cisco engineer on the problem and could never get it to work properly. In the end I ended up putting the cme box on its own wan ip. The problem is/was with the sip invite and the way it is sent. The cisco box would not understand the translation and the call would not connect. I am fairly sure this is your problem. You should be able to do a sip trace and see it happening with your box in the logging. Your box is most likely sending out a sip invite with its lan ip address which will not work even though it is forwarding through the pf box correctly.
-
I had this same problem with a cisco cme. I even worked with a cisco engineer on the problem and could never get it to work properly. In the end I ended up putting the cme box on its own wan ip. The problem is/was with the sip invite and the way it is sent. The cisco box would not understand the translation and the call would not connect. I am fairly sure this is your problem. You should be able to do a sip trace and see it happening with your box in the logging. Your box is most likely sending out a sip invite with its lan ip address which will not work even though it is forwarding through the pf box correctly.
Yep I think I saw that happening, we threw out the Pfsense box and installed DDWRT on an x86 computer, replacing pfsense, but keeping the PBX internal. Everything was up and working like it should of been in less than 20 minutes. HAH
-
I had this same problem with a cisco cme. I even worked with a cisco engineer on the problem and could never get it to work properly. In the end I ended up putting the cme box on its own wan ip. The problem is/was with the sip invite and the way it is sent. The cisco box would not understand the translation and the call would not connect. I am fairly sure this is your problem. You should be able to do a sip trace and see it happening with your box in the logging. Your box is most likely sending out a sip invite with its lan ip address which will not work even though it is forwarding through the pf box correctly.
Yep I think I saw that happening, we threw out the Pfsense box and installed DDWRT on an x86 computer, replacing pfsense, but keeping the PBX internal. Everything was up and working like it should of been in less than 20 minutes. HAH
Welcome to the brave (not so new) world of SIP NAT traversal. It seems that in today's workplace, the majority of IT folks (usually overworked sysadmins, who also have to do the job of net engineers) don't have the knowledge, time or inclination to study complex problems such as SIP NAT traversal, in order to understand the issues involved and be able to debug them.
Instead they'll plug a few "boxes" and just go with "whatever works", as so well expressed by the previous poster.
-
I had this same problem with a cisco cme. I even worked with a cisco engineer on the problem and could never get it to work properly. In the end I ended up putting the cme box on its own wan ip. The problem is/was with the sip invite and the way it is sent. The cisco box would not understand the translation and the call would not connect. I am fairly sure this is your problem. You should be able to do a sip trace and see it happening with your box in the logging. Your box is most likely sending out a sip invite with its lan ip address which will not work even though it is forwarding through the pf box correctly.
Yep I think I saw that happening, we threw out the Pfsense box and installed DDWRT on an x86 computer, replacing pfsense, but keeping the PBX internal. Everything was up and working like it should of been in less than 20 minutes. HAH
Welcome to the brave (not so new) world of SIP NAT traversal. It seems that in today's workplace, the majority of IT folks (usually overworked sysadmins, who also have to do the job of net engineers) don't have the knowledge, time or inclination to study complex problems such as SIP NAT traversal, in order to understand the issues involved and be able to debug them.
Instead they'll plug a few "boxes" and just go with "whatever works", as so well expressed by the previous poster.
It was the fact that pfsense wasn't forwarding the ports, I wasted 14 hours of my life reading and trying different configurations of pfsense with outbound natting and static port mapping and nothing worked. Then I slapped DD-WRT, tried basic port forwarding like I did with pfsense and everything worked.
Pfsense over complicates things, mostly because of FreeBSD.
-
It was the fact that pfsense wasn't forwarding the ports, I wasted 14 hours of my life reading and trying different configurations of pfsense with outbound natting and static port mapping and nothing worked. Then I slapped DD-WRT, tried basic port forwarding like I did with pfsense and everything worked.
Pfsense over complicates things, mostly because of FreeBSD.
Well, if "pfsense wasn't forwarding the ports" I think that more of us would probably have noticed it.
Your description in the opening post reads like a classic case of SIP NAT traversal problem. It's a subject that I've researched quite extensively, using different firewalls/packet filters and different SIP software and ITSP.
Indeed pfsense seems overly complicated compared to DD-WRT.
On the other hand, FreeBSD or OpenBSD are more complicated than pfSense. -
I was never implying that the issue is with the pfsense box. Quite the contrary, the issue is with the way the sip invite is sent to/from the provider and the receiver box. The issue with the cisco was it would not allow a wan ip to be substituted for the lan ip. It only understood that it's sip port was sitting on a lan not the wan. The end result is that it would send the invite to the provider correctly with a reply to of the lan ip address. Also when replying to the provider it would send it's lan ip in the invite the provider would receive the packet through the nat however there is no way to rewrite the sip reply in nat and it will fail.
My response was to suggest that if you can? you need to somehow get your voip box to send it's invites and replies with the wan address of the nat, this has nothing to do with nat and everything to do with the voip box.