FreePBX can't see extensions real IP

Hmmm… Im not sure I understand… How can it work in that case? If I disable NAT (DST-NAT) then I won’t be able to connect to the PBX from outside.

I think you’re getting confused with port forwarding, and NAT. They’re totally different things.

I am afraid they are the same… en.wikipedia.org/wiki/Port_forwarding

I said that because you don’t seem to understand the fundamental concepts of NAT. This is the cause of your problem. Your NAT setup is incorrect. You should get someone in who can resolve this properly.

“You want to port forward incoming connections, and NAT external connections”.

Expanded, you want to SNAT outgoing connections and DNAT incoming connections.

I strongly - STRONGLY - urge you not to mess with this. You don’t understand what you’re doing, and you’re just going to get more and more confused. Perhaps the people who manufacturer the device you’re using for NAT offer support?

Or even better, just throw it away and get a cheap $20 router that will do this with a nice clicky user interface.

I’ll have a bash . . .

Port forwarding is necessary to get your SIP and resulting SDP connections properly redirected through your firewall to your server. Having your Firewall also translate the IP Address is not necessary but is what many “Helper”/ALG’s do (almost always badly) and means that any source address filtering based on SPI can only be done by the firewall, most do not have that ability, so disable any of that functionality on your router or fail2ban will be subverted.

Seeing a bunch of devices behind the same address (albeit with different ports) is normal if the address is a far end router, this is how routers work. Then fail2ban WILL work but one bad user/password extension or any other transgression that the fail2ban regexes catch originating behind that far end firewall will sooner or later cause them all to be banned, That is unfortunate but you need to be able to husband such cases, fail2ban will identify the bad authority or other exploit successfully and you will have to tell the client to just “not do that” or if you fully trust that far end network then add an ignoreip to fail2ban for that network.

Any SIP/IAX2 connections that apparently originate from your gateway’s address, I would normally assume are always illegitimate unless possibly it has it’s own FXO/FXS/TDM/SIP server embedded.

SNAT-ing outgoing connections and DNAT-ing incoming connections was done already… I am using MikroTik router and I can;t change it to any cheap thing because I have so many options with mikrotik. VPN between some points is one of them.

Mikrotik has a built in SIP “helper” are you using that? Are you using VPN for your remote extensions?

According to Asterisk, you’re using SNAT (source NAT) for incoming connections, not DNAT.

However, this is a problem with your Microtik device. You should be asking them for support. This is probably something someone there can fix in a matter of seconds, or, you could spend days here :sunglasses:

–Rob

Hi,

No. VPN is used for something else. Extensions are connecting directly and I won’t connect them via VPN. I don’t use built in SIP helper.

Well… Asterisk is wrong. If I disable DNAT then extensions won’t connect. New moment is…
I have changed the settings in one of my extensions in asterisk from NAT=YES to NAT=NEVER. After this asterisk reported different address for that extension but again it was not the public one. :slight_smile: It was the local address of the extension provided by a DHCP from the router where the phone was connected. STATUS=UNREACHABLE. I could make calls from it but not to receive… and, yes, it was one way audio.

Then as Rob suggests you need to reconfigure your Mikrotik, it is masking the “real” registrants and not correctly forwarding the SDP sessions.

Hi Spaxton, sorry to be opening up this thread after 4 years. This is first well articulated thread about a problem we are facing too, on just one of the many boxes we have deployed. Were you able to find the root cause of the problem?

Captured in this ongoing thread… Asterisk Info, Peer report of SIP Peers indicating Host as PBX server IP

Hi Dicko, as you have explained, my hunch was also on the Router (Aztech DSL8800GR), but the fact that Asterisk “sip show peer” does show the correct source IP in “Reg. Contact” field but morphs it to PBX server IP in “Addr->IP” field, causes me to think it may be some interpretation of Asterisk as well.

Appreciate your analysis of our case. Thanks.

Hello Rohit Gupta,

Don’t be sorry, I am glad if I can help You!
I did solve this problem. My problem was that FreePBX really could not see the real source address because all interfaces in my MikroTik router were SRC NAT-ed. This problem is not related to FreePBX but to the router. If You tell me which router You have, I may be able to help You resolve this. I am able to asist You via teamviewer too.

Best Regards.

@Spaxton, Thanks. I suspect this router may be doing SNAT or DNAT too - but since ssh access is closed, I’m unable to confirm and alter it. A general purpose router should generally masquerade.

The router is a Aztech DSL8800GR(S) (ftp://ftp.aztech.com/support/singapore/ADSL/DSL8800GRV(S)%20-%20User%20Manual%20v1.0.pdf).

Hello Friend,

I see this router was provided by Your ISP. I suggest You set it to act as a bridge for internet and buy mikrotik or ubiquiti router. If You need my help, I will gladly assist You…

Best regards.

@Spaxton, thanks for the kind offer to assist and the suggestions. I will keep this thread informed about any progress we make.

No problem. If You need my help, just ping me here.

Best regards.

I have the same issue with grandstream gxp1615 , not sending the public IP. any idea ?

The issue in our case was identified as a faulty router that was not doing the Source NATing correctly. It actually turned out be not just a faulty router but that brand and make of Aztech router has this flaw and no way to correct it. Changing the router sorted the problem. It was not that the IP phone or remote softphone was not sending its WAN IP - the router was handling it incorrectly. You may want to check the same by sniffing the incoming packets first.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.