So how do i get my PBX to answer calls sent to it like that?
My firewall is configured with a 1 to 1 NAT for the PBX meaning the IP address configured with Gradwell is what my firewall should be showing when my pbx sends data to the provider. I’m just wondering, do I need to put my public IP anywhere in the settings even though technically if i browse the internet on that PBX system and lookup my IP online the websites detect me as the correct IP. But not sure for PBX does the PBX also have to send my public IP?
OK so I got it working. It’s actually very simple. The reason it wasn’t working is because in Asterisk settings I had to change IP to static and define the local IP and the public IP. As soon as I did that, it started working
@david55 surprisingly as soon as I made the changes to the settings in the trunk as pictured above based on your feedback, the outgoing call has started to work. So I assuming the insecure setting could have been the only thing that was causing outbound to give busy tone?
Actually, if your other thread ( Lots of unrecognised calls showing in User Panel / Call Monitor ) is correct, incoming shouldn’t work. If they are correct, you should not be able to make chan_sip work for incoming without using guest mode. The fact that it does work suggests that there is only really one valid address for the firewall.
My answer on the other thread assumed you were using the, supported, chan_pjsip driver, which does allow for large numbers of addresses to be matched by IP,
Lol now I am confused lol. The other thread I opened the firewall ports pointing the external IP to the required ports but I limited it to only allow gradwells IP ranges. I also turned off allowguest. I tried each one by itself and both ways prevents the junk attempts in the logs.
So then I created the first pictured sip trunk. When I call my did number, gradwell forwads that call to [email protected]_public_ip I then created a inbound route for that DID to go to a IVR. initially it wasn’t working until I went to the asterisk settings and turned IP to static and specified my local IP network and the public IP address which matches the one approved by gradwell. As soon as I did that, the incoming calls started working.
Now problem was with outbound calls giving busy tone. Then looking at your feedback about certain settings not making sense on first picture, I revised the sip trunk settings to the second picture, and as soon as I did that the outbound calls started working.
So it’s all working now, is something still wrong? Gradwell will be assigning multiple DID numbers to the same trunk
If incoming calls are working for you, they can’t be using any more than 126.96.36.199 and 188.8.131.52 as source addresses, and I’m not sure that chan_sip will actually match both of those. That’s just not consistent with the claim that they could use a wide range of addresses, and that you should not filter by address.
Ok let me see if I’m understanding this correctly. Please pardon my lack of knowledge. I’m a dummy user lol
So by keeping allowguest on, any IP forwarding a call as long as my firewall allows it then the freepbx will take that call and try to deal with it. But I would assume you still need to create trunk to route it. But with this setup it wasn’t working anyway. So then I turned off allowguest and in the firewall only allowed all gradwell IP address ranges. And created the sip trunk. The main thing that made incoming work was me setting the static IP.
So the question is, when gradwell sends a call to [email protected] how comes freepbx isn’t seeing it as a guest and denying it but it’s actually seeing it as an approved trunk. I assume it has something to do with the trunk pictured above. Because without that trunk the incoming calls don’t come.
Because the source IP address matches (the first) IP address returned by DNS lookup on the host= setting for a peer in the right context.
If you had a type=friend section it could also match based on the from user name but Gradwell, like most ITSPs, is using that for the caller ID, or on the authentication user name, but ITSP never, in practice, provide authentication, and in any case, authentication isn’t sent on the first INVITE, but only when challenged. With type=user, the IP address is not used.
chan_pjsip, which you should be using, has a type=identify section, which can list many addresses, and those addresses can be whole networks, not just single, 32 bit, addresses.
Just thinking… if currently I am only allowing the IP ranges that belong to gradwell to come through my firewall to the PBX server on those ports, then technically I could just leave AllowGuest setting ON because with that setting left to ON and my firewall restricted, none of those junk calls turn up on my PBX. So i’m just thinking if what you are saying about the IP addresses and by luck if it’s working now then it may not work at some point because it’s forwarded from a different IP. then is it not easier to just leave AllowGuest on and restrict at firewall level.
That way if it passes the firewall level then it makes it to the PBX because of the allowGuest.
Let me see if in understanding this correctly. Currently with firewall only allowing gradwell IP addresses and allowguest turned off on freepbx. The only reason the gradwell incoming call is getting through is because in my gradwell sip trunk settings as pictured originally few posts above, the hostname is set to “sip.trunk.prod.gradwell.com” and when freepbx is receiving this sip call it’s identifying the connecting IP to resolve to the same Ip configured in the host and hence letting it through? So if gradwell were to use different ip addresses to forward that call, if it didn’t match the connecting hostname IP then it won’t let it through? Is that correct?
So keeping inbound traffic restricted to only gradwell IP addresses at firewall level and turning in allowguest might be the safer option as I dont want it to be working now and then randomly stop if gradwell were to forward the call from different ip
This is becoming even bigger mystery how it’s even working. So I have two firewall rules. One for the outbound ports and one for the inbound port forwarding to the PBX local IP address. Even if i disable the inbound port completely, the external gradwell calls still seem to come through. It’s only by disabling outbound on those ports that it stops coming through. So this has got me thinking regarding my other thread, whitelisting their IP addresses for internal traffic doesn’t seem to be making any difference anyway. It is blocking all the other unwanted sip attempts though.
The question is, how is this even working? How are the calls able to make it through? The one thing that makes a difference and makes incoming and outgoing calls completely stop is if i change Asterisk Sip Settings IP address from Static to Public. It only works on Static with the external IP defined. So this has something to do with it too.
Which log files should I be sharing? there’s fail1ban, full, queue and debug but debug seems to be empty.
It definately isn’t using the inbound firewall rule because if I disable the outbound firewall rule allowing outbound traffic then the calls stop coming through. The inbound one isn’t making any difference to it. It’s making me wonder, could it be registering with gradwell sip and somehow able to know how to receive the call?
I remember having a sipgate account on here a while back and that didn’t need any inbound ports, it just needed outbound 5060 tcp and udp and it would just work. So this is reminding of that
Just had a look at the SIP peers section where all my voip phones are showing registered. At the bottom on the page I see Gradwell with these details:
I just locked myself out of remote access accidently on the firewall and i’m back to work in a week lol. Going to have to report back with the logs when i return lol.
In theory, if i left AllowGuest ON and inbound firewall rule is only allowing the Gradwell IP’s for the following ports:
When i tested this, none of the junk requests were making it to the PBX on the User Panel logs so essentially the firewall is doing what the AllowGuests off was doing. So that’s why i’m thinking leaving it on may just be the safer option to make sure the gradwell routing always works.