FreePBX inbound call issue
-
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@triple9 said in FreePBX inbound call issue:
@samsmart84 Maybe this Sophos KB article will help?
Success! So basically some trial and error with the settings.. I had to turn OFF the Sophos VOIP options as that was actually BLOCKING everything (Go figure).
That’s actually expected. That’s SIP-ALG. Always have to disable that. It’s basically just SIP blocking.
Nice of them to include that as a SIP "feature"
-
@samsmart84 said in FreePBX inbound call issue:
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@triple9 said in FreePBX inbound call issue:
@samsmart84 Maybe this Sophos KB article will help?
Success! So basically some trial and error with the settings.. I had to turn OFF the Sophos VOIP options as that was actually BLOCKING everything (Go figure).
That’s actually expected. That’s SIP-ALG. Always have to disable that. It’s basically just SIP blocking.
Nice of them to include that as a SIP "feature"
It’s so dumb. But every vendor does it. So don’t think too badly of Sophos. Only vendor I know that doesn’t do it is Ubiquiti. And they do it, it just works.
-
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@triple9 said in FreePBX inbound call issue:
@samsmart84 Maybe this Sophos KB article will help?
Success! So basically some trial and error with the settings.. I had to turn OFF the Sophos VOIP options as that was actually BLOCKING everything (Go figure).
That’s actually expected. That’s SIP-ALG. Always have to disable that. It’s basically just SIP blocking.
Nice of them to include that as a SIP "feature"
It’s so dumb. But every vendor does it. So don’t think too badly of Sophos. Only vendor I know that doesn’t do it is Ubiquiti. And they do it, it just works.
Sorry to disappoint, but it Ubiquiti does not have it disabled by default.
You have to disable it.configure set system conntrack modules sip disable commit;save;exit -
@jaredbusch said in FreePBX inbound call issue:
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@triple9 said in FreePBX inbound call issue:
@samsmart84 Maybe this Sophos KB article will help?
Success! So basically some trial and error with the settings.. I had to turn OFF the Sophos VOIP options as that was actually BLOCKING everything (Go figure).
That’s actually expected. That’s SIP-ALG. Always have to disable that. It’s basically just SIP blocking.
Nice of them to include that as a SIP "feature"
It’s so dumb. But every vendor does it. So don’t think too badly of Sophos. Only vendor I know that doesn’t do it is Ubiquiti. And they do it, it just works.
Sorry to disappoint, but it Ubiquiti does not have it disabled by default.
You have to disable it.configure set system conntrack modules sip disable commit;save;exitI know it is enabled, but have you ever seen it fail? It's the one SIP-ALG system that I have seen "just work" in the real world.
-
@scottalanmiller said in FreePBX inbound call issue:
@jaredbusch said in FreePBX inbound call issue:
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@scottalanmiller said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@triple9 said in FreePBX inbound call issue:
@samsmart84 Maybe this Sophos KB article will help?
Success! So basically some trial and error with the settings.. I had to turn OFF the Sophos VOIP options as that was actually BLOCKING everything (Go figure).
That’s actually expected. That’s SIP-ALG. Always have to disable that. It’s basically just SIP blocking.
Nice of them to include that as a SIP "feature"
It’s so dumb. But every vendor does it. So don’t think too badly of Sophos. Only vendor I know that doesn’t do it is Ubiquiti. And they do it, it just works.
Sorry to disappoint, but it Ubiquiti does not have it disabled by default.
You have to disable it.configure set system conntrack modules sip disable commit;save;exitI know it is enabled, but have you ever seen it fail? It's the one SIP-ALG system that I have seen "just work" in the real world.
Ah, I misunderstood.
I have not because I always disable it.
-
Reviving my thread -
Weirdest thing. We had a power failure/surge over the weekend which knocked down all my servers, switching, etc.
My phones have been working FLAWLESSLY since I last posted. But now, after getting everything back up and running, the SAME issue is back.. but the rules that fixed it before are still in place! Outgoing calling works (though it seems highly delayed now.. like 5-8 seconds after dialing a number for it to start ringing) but I CANNOT call in UNLESS I call out first, which fixes it for 2-3 minutes.
Once again, it's gotta be a firewall issue. This is stupid.
-
Okay.. so now I'm more confused than I've ever been. I deleted my DNAT and my outbound rule for my SIP provider and now it works. Flawlessly. WHAT!? How do the calls know where to go!?!?! Did my Sophos UTM get superpowers after a power spike?
-
@samsmart84 said in FreePBX inbound call issue:
Okay.. so now I'm more confused than I've ever been. I deleted my DNAT and my outbound rule for my SIP provider and now it works. Flawlessly. WHAT!?
I never understood what your router was doing in the first place. So any number of things might be the issue.
-
@jaredbusch said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
Okay.. so now I'm more confused than I've ever been. I deleted my DNAT and my outbound rule for my SIP provider and now it works. Flawlessly. WHAT!?
I never understood what your router was doing in the first place. So any number of things might be the issue.
Well false alarm.. it's not actually working
Firewall Rule:
Internal Network > SIP > AnyIPv4DNAT:
SIP Trunk > SIP > Public IP > Internal SIP Server -
Because nothing is hitting your PBX, you need to get a packet capture from the WAN side of the router.
You may need to drop a switch with the ports configured for mirroring and such in between your ISP modem and your Sophos in order to get this. Or Sophos may have the capability.
Contact Sophos about that bit, I have no clue.
-
I have been watching the logs for the last day or so as I've been testing. I've noticed on the Sophos that when the inbound calls don't work I get a hit on the firewall logs for my DNAT rule for my VOIP Provider > External WAN on port 5060
When inbound calls DO work, I get a hit for my DNAT rule, same IPs, but the port always shows as one of the RTP ports. So either way the calls ARE hitting at least the WAN interface and I'm getting a different response on the firewall depending on whether it works or not.
-
@samsmart84 said in FreePBX inbound call issue:
I have been watching the logs for the last day or so as I've been testing. I've noticed on the Sophos that when the inbound calls don't work I get a hit on the firewall logs for my DNAT rule for my VOIP Provider > External WAN on port 5060
When inbound calls DO work, I get a hit for my DNAT rule, same IPs, but the port always shows as one of the RTP ports. So either way the calls ARE hitting at least the WAN interface and I'm getting a different response on the firewall depending on whether it works or not.
There we go! You should not be getting anything inbound on port 5060. You do not need an inbound port forwarding rule for anything if your trunk is a standard register trunk going outbound. That outbound registration will keep the NAT tunnels alive and allow everything to work with zero port forwarding rules.
-
There are only two occasions when you want to port forward the traffic for your voice over IP.
Condition one if you have external phones.
Condition to is if your sip trunk provider does not use registration but instead uses IP validation. This is a rare case normally.
-
@jaredbusch said in FreePBX inbound call issue:
There are only two occasions when you want to port forward the traffic for your voice over IP.
Condition one if you have external phones.
Condition to is if your sip trunk provider does not use registration but instead uses IP validation. This is a rare case normally.
My SIP provider does actually use IP validation instead of registration.
I put in a support ticket with Sophos and they went through all of the rules/logs and confirmed that traffic is getting through both ways on the firewall. When inbound calling it is in fact being forwarded to the PBX, but the PBX is not responding back, which is why I'm getting dead silence on my inbound calls.
-
@samsmart84 said in FreePBX inbound call issue:
@jaredbusch said in FreePBX inbound call issue:
There are only two occasions when you want to port forward the traffic for your voice over IP.
Condition one if you have external phones.
Condition to is if your sip trunk provider does not use registration but instead uses IP validation. This is a rare case normally.
My SIP provider does actually use IP validation instead of registration.
I put in a support ticket with Sophos and they went through all of the rules/logs and confirmed that traffic is getting through both ways on the firewall. When inbound calling it is in fact being forwarded to the PBX, but the PBX is not responding back, which is why I'm getting dead silence on my inbound calls.
Actually no that’s not what was happening before. Before when the inbound calls were not working nothing hit the PBX
-
@jaredbusch said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@jaredbusch said in FreePBX inbound call issue:
There are only two occasions when you want to port forward the traffic for your voice over IP.
Condition one if you have external phones.
Condition to is if your sip trunk provider does not use registration but instead uses IP validation. This is a rare case normally.
My SIP provider does actually use IP validation instead of registration.
I put in a support ticket with Sophos and they went through all of the rules/logs and confirmed that traffic is getting through both ways on the firewall. When inbound calling it is in fact being forwarded to the PBX, but the PBX is not responding back, which is why I'm getting dead silence on my inbound calls.
Actually no that’s not what was happening before. Before when the inbound calls were not working nothing hit the PBX
And it still fails to show anything on the PBX when it comes up blank.. but Sophos shows it as being pushed to the PBX with no drops! How the heck am I supposed to troubleshoot that?
-
@samsmart84 said in FreePBX inbound call issue:
@jaredbusch said in FreePBX inbound call issue:
@samsmart84 said in FreePBX inbound call issue:
@jaredbusch said in FreePBX inbound call issue:
There are only two occasions when you want to port forward the traffic for your voice over IP.
Condition one if you have external phones.
Condition to is if your sip trunk provider does not use registration but instead uses IP validation. This is a rare case normally.
My SIP provider does actually use IP validation instead of registration.
I put in a support ticket with Sophos and they went through all of the rules/logs and confirmed that traffic is getting through both ways on the firewall. When inbound calling it is in fact being forwarded to the PBX, but the PBX is not responding back, which is why I'm getting dead silence on my inbound calls.
Actually no that’s not what was happening before. Before when the inbound calls were not working nothing hit the PBX
And it still fails to show anything on the PBX when it comes up blank.. but Sophos shows it as being pushed to the PBX with no drops! How the heck am I supposed to troubleshoot that?
With the packet capture on up near port of the port going to the PBX
-
So I messed with my SIP trunk settings and inbound calling changed from dead silence to a busy signal so it's definitely getting through the firewall.
-
Well it appears to be working now... the busy signal lead me to think I could possibly tweak the trunk settings further on the PBX to get it all working. Switchd nat=no to nat=yes (Not sure why that didn't matter last time) and I also added qualify=yes. Looks like this explains why -
https://www.voip-info.org/asterisk-sip-qualify/
Interesting that this was working before without requiring this
-
@samsmart84 said in FreePBX inbound call issue:
Well it appears to be working now... the busy signal lead me to think I could possibly tweak the trunk settings further on the PBX to get it all working. Switchd nat=no to nat=yes (Not sure why that didn't matter last time) and I also added qualify=yes. Looks like this explains why -
https://www.voip-info.org/asterisk-sip-qualify/
Interesting that this was working before without requiring this
Wow, that trunk is fucked up if you did not have those set...
I am surprised shit ever worked.This is a typical SIP trunk setup.
username=TRUNKUSERNAME type=friend trustrpid=yes sendrpid=yes secret=TRUNKPASSWORD qualify=yes nat=yes insecure=port,invite host=TRUNK.IP.ADD.RESS fromuser=TRUNKUSERNAME context=from-trunk canreinvite=nonat disallow=all allow=ulaw
