I don’t understand what you are saying. I didn’t ask you to change any settings. Just verify that the ones I mentioned are correct, but post a better log that includes a SIP trace.
My firewall only passes SIP RTP UDP 10000-20000 from NEXVORTEX provider NOT any
My firewall only passes SIP UDP 5060-5082 from NEXVORTEX provider NOT any
PBX 12 is a working live system. not being touched.
Trying to get PBX 14 to work, its installed in the same networks.
The PBX12 im trying to replace/upgrade.
Also have a test PBX 15 built, but have the same issues
Fix that. See p. 9 of the nexVortex guide I linked:
1 Like
Solution #1
Opened rtp ports from all
hear VM now.
THANK YOU…
Still working out bugs…
5060 open to provider
10000-20000 open to all
Makes complete sense…
these chan_sip settings working PBX12 for 6+ years… see final sokution
its an RTP issue, the 5060 setting unchanged
While your solution will work, it is a bad solution, as you have opened the gates of your PBX to the world on ports 10000 to 2000. I don’t know that there are any exploits on those ports, but the nature of software is that we don’t always know about the exploits.
If I had to guess, I would guess that is what happened…
Your firewall’s “related/established” rules know that port 5060 is SIP. When it sees an outbound packet from 5060, it knows to expect a response on both 5060 AND on 10000 to 20000. This is expected behavior and so the firewall automatically accepts replies coming from your ITSP those ports, and forwards them onto your PBX.
Your old system had chan_sip set-up to use port 5060 and you had a chan_sip trunk on your old system. Asterist sent out traffic to your PBX (and to wherever else it needed to) from Port 5060. Your router knows that 5060 is a SIP port, and so it faithfully watched for return traffic on 5060/10000-20000 and returned it to your PBX without you having to think about it.
Unfortunately, the FreePBX devs have decided that the the fully functional, mature, stable, and deprecated chan_sip should be moved to port 5061, and so when you installed your new system, it was configured to use PJSIP on port 5060 and chan_sip on port 5061. When you configured your chan_sip trunk, it caused Asterisk to send out SIP requests from port 5061, and not port 5060.
Your router, however, was never told about this change. It doesn’t know that port 5061 is a SIP port. More specifically, port 5061 is not traditionally a SIP port and so your router isn’t programmed to watch for responses on 10k-20k. So, when an outbound packet goes from port 5061, your router’s “related/established” rule doesn’t watch for, accept, and forward packets bound for port 10000 to 20000 back to your PBX. It just blocks them. It is still watching 5061 for return traffic, because it does that with every port.
The solution you’ve come across will work, but it’s not ideal. The better solution is to either:
- Configure your trunk as a PJSIP trunk
OR
- Disable PJSIP, change the chan_sip port back to 5060 (like it was on your old system), and configure your trunk as a chan_sip trunk.
Either should work, just as your old PBX worked, and you won’t have to forward ports.
And for clarification, the router behavior that I’m describing has nothing to do with SIP ALG. SIP ALG attempts to rewrite the SIP headers. It’s totally different.
Guess you have never heard of signaling and media coming from different IPs.
2 Likes
You’re mistaken. I’m fully aware that signalling and media can come from different IPs.
While I understand why you think that it is, you have to accept as true his statement that his OLD system worked just fine. If his old system worked just fine and the new one doesn’t work, then media coming from different IPs is not the problem.
There’s also a reason why this will still work even if media comes from a different IP, but I don’t have the time to explain it to you right now, and it doesn’t matter because:
his OLD system worked just fine
Aware,
For now I need the system to work, and configure IVRs and the like, as well as remote extensions,
ill get back to securing the server later
5061 and TLS for another day
Thank you
Considering we aren’t helping him troubleshoot his old system, I wasn’t particulary interested in it.
By looking at the config and logs he posted I can see that the signaling and media addresses are different.
Stewart already gave him the correct solution. Why come along and add misinformation?
False.
Then what are you talking about? There is no router out there that sees 5060 traffic and goes “oh, this must be Asterisk and I should open 10000-20000 udp inbound”. Is there a upnp module I’m unaware of? What you’re saying sounds great, but how?
if Asterisk looks at the SDP and starts sending media first and thus opens the reverse path, and both sides agree about symmetric RTP, yeah it should work.
Absorbing info…
There wasn’t anything wrong with his old system. It was working fine.
Stewart’s “solution” is unnecessarily opening a massive security hole in his system. And I’m not providing misinformation.
I suggest that you educate yourself on iptables, and the difference between the “related” and the “established” rules when using Iptables.
Port 5060 is a SIP service port. Ports 10000-2000 are RTP ports. RTP is related to SIP, and so routers that use Linux and Iptables (most of them) can recognize traffic originating from port 5060 and then accept new connections on ports 10000 to 20000 if the “related” option is enabled (which it is on most routers by default).
This also has nothing to do with UPNP. Totally different. And frankly, while I could understand someone thinking that this has to do with SIP ALG, your reference to UPNP is incomprehensible.
What I think @billsimon is saying is that RELATED,ESTABLISHED doesn’t have anything to do specifically with 10000-20000. It will allow the connection on whichever port(s), as long as it was previously whitelisted in another iptables rule (e.g. whitelisted IP, or port 5060). It has nothing to do specifically with RTP.
ESTABLISHED does not. RELATED does. Iptables is programmed to recognize service ports that are related to one another. One of those relationships is SIP signaling and RTP. To Iptables, they’re like bread and butter, or peas and carrots.
Note that when I refer to Iptables, I’m really referring to the Linux Packet Filter in the Kernel. Iptables is just a front-end.
You are splitting hairs and missing the point of my post. I’m merely attempting to explain Bill’s response to your post regarding RELATED,ESTABLISHED
And while we all madly post, declaring rtp to use 10000-20000 will cause about one call in 2500 to have one way audio., it should be fixed.
Let’s not go down that road. Mark Spencer developed a perfectly good alternative (IAX2 - which uses 4569 for everything), but I don’t think anyone else will use it as long as the word “Asterisk” is in the name.
I’m not splitting hairs. I’m saying that Bill is wrong.
ESTABLISHED won’t look at an outbound packet originating from Port 5060 and do anything other than watch for a response on the same port.
But, “RELATED” will. “RELATED” tells the firewall (and NAT if enabled) to watch out for new inbound connections that are RELATED to the outbound request. SIP 5060 and RTP 10k-20k are recognized as “RELATED.”
All of this “magic” is done using the Linux CONNTRACK module. SIP and RTP have been related since Linux Kernel 2.6.18 (released in 2006):
https://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html
Christian Hentschel
chentschel at people.netfilter.org
2005-04-09The SIP conntrack/NAT extension support the connection tracking/NATing of the data streams requested on the dynamic RTP/RTCP ports of a SIP session, as well as mangling of SIP requests/responses.
https://sipfoundry.atlassian.net/wiki/spaces/sipXecs/pages/491868/Configure+iptables
The SIP conntrack/NAT extension supports the connection tracking/NATing of the data streams requested on the dynamic RTP/RTCP ports of a SIP session, as well as mangling of SIP requests/responses.
SIP conntrack/NAT extension for netfilter/iptables is currently available from netfilter patch-o-matic.
SIP conntrack/NAT extension is available in the mainstream kernel as of 2.6.18.