We’ve got a PBX appliance that has been working with both inbound and outbound calling. However recently some firewall changes needed to be made. The system does seem to be allowing traffic to pass and outbound works no issue.
We had anonymous calls and SIP guests disabled and the trunk worked fine.
The changes to the firewall basically were the previous configuration had the box essentially DMZed and all traffic was free to flow to the box. However obviously security wise that’s no good and now that we took over management we’ve modified it to just forward the ports needed. (5060, 5160, 10,000-20000)
However in this instance now the logs indicate a 401 unauthorized when inbound calls are coming in.
Basically the inbound invite is showing as the 8 digit number 1-AreaCode-XXX-XXXX
which is how the inbound route is setup to match including the 1, this worked fine prior to firewall changes.
The 192.168.0.254 is the gateway / firewall. So I’m curious what is being over looked that after changing from DMZ to VirtualIP / service forwarding (It’s a fortunate).
Would now cause it to give a 401 unauthorized, is it somehow modifying the information now?
The Service provider is voip innovations, and setting anonymous and sip guest to On enables the call flow to work, turning those back off the calls are rejected
Thanks if I can provide any more log information let me know
not having insecure=invite (or better, but possibly not supported by FreePBX, remotesecret instead of secret), or
the From: header is matching an extension declared as type=friend, or
the source IP addess is not matching the host= on a type=peer or type=friend, and the From: is not matching a correct type=user or type=friend, and you have alwaysauthreject.
Per our providers configuration instructions we have a SIP Trunk (not PJSIP) configured, on the provider end it is configured to use 5160 also for SIP.
We also only have outbound information configured in the trunk settings, the inbound information is left empty.
Their instructions are as follows for Outbound SIP Trunk settings;
Host=THEIR IP
type=friend
insecure=port,invite
dtmfmode=rfc2833
disallow=all
context=from-trunk
allow=ulaw
Their “security” is based on IP, on their portal we configure the IP of the system.
On an incoming call, Asterisk uses the source IP address to determine which trunk is making the call.
You need to configure your router/firewall so it preserves the source address when forwarding external packets to the PBX.
Alternatively, you could set up a second trunk, just like the first, but with host=192.168.0.254
You would continue to use the first trunk for outbound calls. On incoming, Asterisk would recognize the 192.168.0.254 address and allow the call to be processed by your Inbound Routes. However, you need to make sure that the router only passes packets from your trunking provider (and any other authorized sources), because Asterisk will be unable to distinguish one source from another.
I believe that the latter method will give you trouble with e.g. external extensions and possibly other situations.
The forwarding setup you implemented is simply wrong for Asterisk.
Could you provide some clarity? What do you mean the forwarding setup I’ve implemented is wrong? It is the same procedure all other documentation says to follow. I have simply followed fortigates instructions for forwarding traffic.
I will check to see if there’s a configuration change that can be made so that its passing the original IP along and not the gateway
Maybe you could say that Fortigates recommended implantation is wrong, but we have countless systems that have forwarded ports behind a firewall and work without an issue. So if anything Fortigate is implementing it in a different method.
All we’ve done is created rules with Fortinets Support technician that has the FreePBX setup to pass along traffic for the respective required ports.
Yeah unfortunately I’ve checked those, went down the same path as you after googling what you mentioned I’ve already verified NAT is OFF on all rules… So I will do some more testing tomorrow and possibly get with their support.
Thanks for your help at the very least I know what rabbit hole to try going down now. It seems that the issue is as you say the traffic coming in is being masked as the gateway .254 private address where as before it would of been correctly showing the provider IP address.
So it seems I will have to determine why the Fortigate is masking the address so thanks for the clarification
They are not. Your error clearly shows they are using 5060, which is presumably going to PJSIP, which doesn’t have an entry, and is presumably sending 401 to make the “hacker” waste time on non-existent extension numbers.
Most providers will work at least as well with chan_pjsip, even if they claim not to support it.
Especially if the provider provided your configuration information you should note that type=host is more secure and that insecure=invite does nothing without a secret, although you may need insecure=port, assuming the call being rejected in your logs is legitimate.
if I can provide any more log information let me know