I am puzzled by this one. On one installation of FreePBX/Asterisk 13, in the Asterisk Info Peers report, I notice that all remote SIP peers are indicating Host as the PBX server IP address instead of reflecting their WAN IP source, from where they are connected (refer enclosed picture). The registrations and calls are working perfectly. However, since every remote connection is presenting PBX IP, Fail2Ban is going for a toss - as every hack attempt is also reflecting with this IP hence, all remote users get banned enmasse. Adding the PBX IP to whitelist will make the whole IP security futile. I am curious to find why is this happening in the first place. Have compared config-to-config line by line for all config files esp pertaining to NAT, but cannot make out the cause for this. Is it possible the Router behind which the PBX currently sits may be presenting this IP instead of the source IP?
Identified that Asterisk seems to be receiving the Reg. Contact accurately but somehow the Addr->IP (both fields listed in show peer username command) is getting modified to the PBX IP itself. Still unable to find the root cause for this.
Has anyone faced this? Any experience with this kind of difference?
6 extensions are remote (coming over public internet) and 8 are local (connecting over LAN) to PBX. What role may the number of extensions have in this problem? This is a common configuration that we deploy - but seen this difference only on one setup. Could the SIP ALG or so playing up on the Router causing this?
That’s a keen observation on extensions and NAT, Tom.
Let me share a brief background. We are making a wireless UC product that uses Asterisk/FreePBX for telephony. In order to popularize IP based telephony amongst small businesses, we have tried to simplify the telecom tech and made it plug-and-play for most common uses. Idea is to not require users to do complex configuration, irrespective of local or remote users. Hence, treating all users behind NAT by default, unless the network warrants a change due to layout or other use-case requirements. This config is working in over 25 locations but in this one location, I am noticing the morphed IP for remote users.
Like I mentioned, the system and calls are originating/terminating perfectly - just that this is causing brute-force protection to go kaput. I have manually compared all asterisk config files under /etc/asterisk between this system and other system where the IPs are recorded accurately as expected - and see no differences other than the environmental differences.
One key difference that is unique to this location is that it uses a private SIP trunk - hence, has two WAN eth ports active - with two isolated networks - one for internet and one for SIP trunk.
On turning on logs, I noticed that local address is reflecting as remote address too, just with a different port number.
I am enclosing the Asterisk sip settings screen below for your reference - but essentially, nat is set to route (so using rport and comedia) and there are four networks marked as local. Let me know if any other settings/log would be useful. Thanks.
Unfortunately, no resolution, but the explanation hovers around doubting the router, which is a strong suspect in my opinion too. I did look at all possible configuration in this Aztech DSL8800GR router but to no avail. Frankly I don’t know what I should be looking for - I generally looked for NAT or SIP related settings, and there are none. Just the port forwarding rules that we’ve added.
But the fact that “sip show peer” is showing correct source IP in Reg. Contact field but replacing it with PBX IP in the Addr->IP field and using that to display as Host in Chan_sip Peers report is puzzling and causing me to also doubt some config in Asterisk playing up.
OK so there are a few issues with this. First, pointing to a 4 year old thread isn’t going to help. Things have changed in the last four years and they could pretty much be irrelevant. Second, you’ve made custom modifications and well that means you’ve changed how FreePBX normally works. That can be an issue. Third, you’re not understanding how this is working in regards to the Addr->IP and the Reg. Contact.
The Reg. Contact is actually what is in the Contact Header sent by the device. The Addr->IP is the Received Address i.e. the public WAN the request came from. So like I said, if you are seeing the Asterisk IP there instead, you have NAT/network configuration issues.
Without seeing what “custom” work you’ve done, no clue as to what the actual issue is. Is there anything different about this box then the others you’ve done? Are they in the same locations? Do they go on-premises?
Tom, you’re right - the other thread symptomatically looks similar but could be different underneath. The thread doesn’t document Asterisk versions in play, so can’t be sure.
Thanks for explaining the interpretation of the two fields. I was under a wrong impression that probably Addr->IP is derived from Reg. Contact in someway, but probably per your explanation, they are two independent fields populated independently. (An aside, can you please point me to any document that explains all these fields and their source of information?). Is there any line of investigation you can suggest to carried out on the Router? What typically should be looked at? I could not find a explicit NAT/SIP related settings on it. I could enable logging on it and see if it throws anything.
All boxes are in different locations; they deploy on-premise and sit in client’s existing networks, over wire or wirelessly. Our box is also an integrated wireless router in itself, in addition to UC/PBX. However, asterisk/freepbx is configured under prescribed norms. As I stated earlier, on networking front, there are four local networks, NAT is set to route for SIP peers as well as trunks (in Advanced as well as SIP and Extensions settings for all users).
Sorry if this information is insufficient to draw some ideas or suggest an investigative path. Please suggest whatever best you can and feel free to ask for any specific data/log that can help assess. Thanks.
The Reg. Contact comes from the Contact Header which contains the contact information about the user. In other words, where this Contact exists and requests/replies should be sent to. Since all these endpoints are sitting on networks behind NAT, the Contact Header is going to contain the Contact User (generally the SIP user) and the local host of the device (its IP).
When the PBX is on the same network or Layer2 then having the RFC1918 (private) IPs is not a big deal because everything is using RFC1918 IPs. However, when the devices are “remote” and require the device to communicate over the Internet then those IPs can’t be used. Many devices have NAT settings where you can tell it what the external IP/Ports are to be used. Some devices are “NAT Aware” and realize they are behind NAT and will attempt to use the external information. Finally, some routers will “repair” the packet and replace the RFC1918 IPs with the external information.
So in your case all the devices should be registering to the PBX and their Addr->IP should be their WAN/external IP of their network. The Reg. Contact field will either be their local IP or if the device/router was smart enough, it would have the same external IP as the Addr->IP. If you are seeing your PBX’s IP as their Addr->IP then you have a configuration issue some where or perhaps their router/network is doing something. Again, this is a NAT/Network based issue. Where that issue is could be on either side or both.
What do SIP debugs or traces show when these devices are REGISTERing to the PBX? What do you see in the Contact Header, the Via headers, etc, etc. That is going to give you a big clue as to what is going on.
SIP traces via security messages show the same ASTERISK.WAN.IP but with different port numbers in LocalAddress and RemoteAddress fields.
Tcpdump trace of a registration request indicates in IPv4 header in field Source, ASTERISK.WAN.IP, and in Destination field ASTERISK.LAN.IP. In Message Header, both From and To fields contain ASTERISK.WAN.IP and Via / Contact headers show “Sent-by Address” and “Contact URI Host Part” fields pointing to same DEVICE.SOURCE.LAN.IP and ports.
From the IPv4 headers it is seeming that the router is goofing up.
None of this tells me anything without seeing the actual debug and the transaction. As well this needs to be run from inside the Asterisk Console tcpdump is going to show you everything before Asterisk touches from the console shows how Asterisk processes it.
I think the big inout here is your stating the PBX is also setup as the router. Sounds like you have some bad NAT or routing rulea at the Linux level somewhere that is replacing the IP with the router IP which also happens to be your PBX IP.
@BlazeStudios, can I share the logs privately for you to look at the tcpdump? From our analysis here, we feel it is Router which is changing the source IP in the very beginning before passing it us or Asterisk. But interestingly, like you pointed and I rechecked, “Reg Contact” continues to have the correct IP listed but that is not used I believe. Not sure what may be its utility or for informational purpose only - or probably used until pre-NAT threshold. I reviewed the Aztech Router settings once again - I could find just two check boxes for “nat” and “fullcone nat”. Both are enabled. Neither should be turned off. The other two checkboxes are for “firewall” (on) and “igmp multicast” (off) - which I don’t believe may be interfering with the way its setup currently.
@tonyclewis, our box has multiple ports, and router is only on wlan interface - currently none of the devices are coming in via that interface. Secondly, the router capability actually has helped us manage this in all other locations except this one location. Tcpdump is indicating the source being modified before we receive.
This is an interesting problem to understand and solve, hence, not giving up yet.
Ok but where are you getting a TCPDump from. What box and if your PBX which interface. I am still wagering bet it’s something with your router on the same box.
Following run on the linux console of the box, tcpdump -n -vvv -s 0 -i eth0 -w /tmp/tcpdump.pcap port 5060
I am not exempting our box or routing tables on it from the root cause. Currently, it could be the edge router, our router/routing tables, or asterisk/nat. It does look related to nat and is something very specific to this deployment - which has an additional eth port and two additional private networks (for private sip trunk) defined as local networks to exempt nat’ing. No users come from this private network - used only for sip trunk.
And which interface is eth0. I would start with a packet capture outside of the Linux box to see what the phone is sending. That will let you know if it’s the Linux box messing it up or something before it reaches that.
@tonyclewis, here’s the list of interfaces and brief about routing on our box.
eth0 - up, LAN/internet eth1 - up, sip private network wlan0 - up, wireless LAN running dhcp (currently no users connected on it. JFYI - Our box can toggle wlan0 for use as Router or use wlan0 to connect to LAN as wireless client, not both simultaneously) ppp0 - down, used for backup access to internet over GSM when needed (not used in this box)
NAT on eth0, eth1, ppp0 with postroute masquerade action, and packet forwarding between eth0, wlan0 and ppp0.
Currently all users are reaching our box on eth0 via an edge router by port forwarding.
We have remote access (via ports) to our box but capturing tcpdump trace outside the box may have some logistical challenges. Let me check.
@Jas_williams, I have scanned the router interface with a microscope but could not find any sip or sip alg settings. It does have nat and fullcone nat but both are needed. The router also seems to be built on open-wrt, which does not have sip alg support, so unlikely it is using that. No cli interface to confirm this.
