0

understanding IP restrictions

Jim smith

April 17, 2018 16:39

None

Follow

Just so I understand IP restrictions clearly, I have a client with 3 remote sites,  In the firewall I have setup a rule to prevent the system from blocking those IP addresses.  Occasionally, we get hit with a bogus ip address that connects to one of the phones and causes havoc.  

All three locations have a static IP address.  Is it safe to assume that if I add the static IP address to each phone at each location, then those phones would only register and allow calls from the restricted IP address?

Here is what is happening that I want to prevent:

Ext 101 is located at static IP address of 172.87.142.50

I looked at the monitor to see that  IP: 74.118.138.71 was also attached to the phone which rendered the phone useless.  If I restrict the IP address to 172.87.142.50 it should then only allow connection and registration from that IP address.  Correct?

• Facebook
• Twitter
• LinkedIn

19 comments

• 
  Jonathan E April 18, 2018 22:25 Official comment

  Jim;
  
  You are correct about what the IP restriction feature does. I also have tested it and find it to be working.
  
  As for best practices, I wouldn't restrict it down to the exact IP. I would suggest opening up the netmask in the restriction to 255.255.255.0 so that the entire block of IPs surrounding your IP are allowed. I do understand what you want to do, and expect it to function with the precise restriction, I simply suggest you consider being less specific as a rule of thumb with this setting. 

• 0
  
  Larry Neblett April 18, 2018 02:50

  To clarify, you have a PBX at one site and then there are two other remote sites that have phones which also connect back to the location with the PBX, correct?

  There are several issues that seemingly come about based upon your description. 

  Presumably, each location has a router and the phones sit behind the routers. The private IP of a phone is only applicable to the local LAN behind each router and have no real bearing on the other sites, unless there is a VPN between sites. So, the idea of statically assigning a private IP to each phone is certainly desired, it really plays no part in what the location with the PBX will see or do with it. 

  I should point out that the IP of 172.87.XXX.XXX is not recognized as a private LAN segment. This is actually a part of the IPV4 public space as the private space only goes to 172.31.255.255. 

  So consider the following, where does the PBX respond when it sees a request from a remote phone? It obviously cannot really reach 172.87.XXX.XXX directly as the message has to traverse the remote router, which does have a public IP, first. 

  The phone shows registered at the PBX with the private IP because the private IP is what is in the contact header that the remote phone sent when registering. 

   

  More later as it is late.

• 0
  
  Oscar Colka April 18, 2018 02:56

  I believe you are correct, see what Yeastar comments:

  

• 0
  
  Larry Neblett April 18, 2018 12:37

  The ideal way of hooking up remote sites is to use a site-to-site VPN. As long as each is using a different LAN segment - 172.35.1.0, 172.35.2.0 and 172.35.3.0 as an example, then you can treat all as being local and use the local IP of each phone. If a VPN is not possible. then - 

  As mentioned earlier, the phone sitting behind the remote  routers are only reachable by a message being directed to the remote routers public IP and then (possibly) letting the router manage to which phone the message is destined. To prove the point, you could try and reach the remote phone's web interface by trying 172.87.XXX.XXX:80 and I can guarantee it will never reach your remote phone. However, as you are using a public space IP, I may be able to connect to something somewhere else, but never the phone. 

  I indicated possibly in the earlier with regard to the router as here is what happens:

  When the phone initiates a call, it sends an INVITE to the PBX. The PBX IP is populated in the phone using the SIP server field, which is presumably populated with the public IP or FQDN of the site where the PBX resides. Note that you are not using the private IP of the PBX. When the message arrives at the PBX router, the router has port forwarding so that the router knows to which private IP (the PBX) to deliver the message. Upon receipt of the message the PBX responds, but the PBX responds to the public IP of the router where the phone that initiated the request sits behind. The phone router then directs the message back to the phone that initiated the request by using the phone's private IP. 

  The issue that may arise is that if multiple phones sit behind the same router, the router may have issues in maintaining the proper NAT/PAT tables and issues may arise. The routers know nothing more than there IP and what instructions have been implicitly stated in rules or rules that are implied by virtue that when a request is made from behind a router to the outside. A port forwarding rules is implicit in that it will process any message at any time and deliver same when the port and protocol match the rules to the stated private IP. Implied rules are when a device sends a message to a device on the other side of the firewall (Internet) and then keeps the port open for a period of time in anticipation of a response. After that time, the port will close and no further traffic coming back in will be allowed. With multiple phones sitting behind a firewall, all communicating to a single PBX, the PBX messaging will be directing the responses back to the public IP which then relies upon the remote router to know which message should be directed to which phones' private IP. The router is not aware of extensions, so it must maintain a table to know which phone generated which request so that each phone will only get the responses in answer to their requests.

  There are a couple of ways around the issue, but the one thing that you should do is to look in the phones' web interface at the remote sites and look for a setting called NAT IP or similar. This field should be populated with the public IP of where the phone is located. This then alters how the phone generates its messaging and instead of sending its own private IP, will now use the public IP so that the PBX will know how/where to send its response correctly. Then. also within the phone, there are settings for local SIP and local RTP ports. In order to help the router maintain the correct tables, these fields should be set up so that each phone that sits behind a given remote router should use a different SIP port as well as local RTP ports. The phones will still be sending their messages to the PBX using 5060, but you want the PBX to send back the responses to 5060 for phone 1, 5062 for phone 2, 5064 for phone 3, etc. The same with the RTP ports (voice), As each message and stream is unique, it will assist the router in trying to keep things straight. As you have stated that each phone has a reserved or static IP, then you can also do port forwarding at each remote router so that all 5060 and RTP port 5004 go to phone 1, 5062 and 5006 go to phone 2, etc. You could also enable keep alives on the phones as this does the same thing. By sending a packet periodically, it becomes an implied rule. The router will keep the port open for a period expecting the possibility of a reply. 

  As stated, there are several ways of handling remote sites- VPN, SBC or the above. The above is the most time consuming and because of the multiple ports being open for SIP, is the most prone to hack attempts, but it also the most reliable way. Not opening ports is really not an option as if the PBX sends an INVITE, the port must be open in order for the INVITE to be seen by the phone. Keep alives fundamentally keep the ports open, despite what some may think. Only when the phone is off-line will the keep alive cease and the port close, but who cares at that point as the phone is off-line anyway? So, if the same were to happen with port forwarding being in place, the message would be sent to the phone, but no response or action would come about as the phone is off-line....the same thing. 

  To stop the rouge or ghost calls, this is not a PBX issue, but rather someone who is sending INVITES to the phone directly. If the INVITE were to be sent to the PBX, the PBX would either reject the INVITE outright as the extension being used is not one that is on the PBX or the PBX will challenge the INVITE and expect an authentication to validate the INVITE, which is most unlikely. This really amounts to someone using IP dialing such as sending an INVITE to 100@74.118.138.71:5060, which I assume to be one of the remote router's public IP addresses. If there is an extension 100 behind the router and the ports are open and the router has a NAT/PAT table with  that entry (highly likely if keep alives are enabled) then the phone will get the INVITE and start ringing. When the phone is answered, there will be no one on the other side, but chances are that the hack will continue until the person originating same gets bored and moves on or you stop same. There are programs that specifically scan sites and then initiate attacks against same in the hope that they will hit upon some that will allow them access to make calls. 

  Again, looking at the phone web interface at the remote sites, look for a setting along the lines of accept messaging from sip proxy only. There are settings in the phone that will limit the messages they will accept such that only messaging from the PBX is the only one allowed. You may need to consult the admin manuals for the phone make and models you have. Conversely, you might also be able to set-up firewall rules on the routers to only pass SIP packets from the desired IPs (this would be public IP only). 

  The IP restriction that Oscar has shown is a second line of defense. If you input the IP 173.87.XXX.XXX it will be to no avail as this is not the IP that the PBX is really responding to or seeing. While not stated in the manual nor the web page info icon on the PBX, it should be the same mechanism that was employed in the MyPBX series which stipulates "Note: if it’s for remote extension, a static public IP address is needed to input instead". As it is physically impossible for the router or PBX to send or receive a message directly from or to a device that is remote and sitting behind a router/firewall which is not on a VPN, the public IP is the only one that will have an effect. However, this setting is not really addressing the issue. As the ghost calls did not traverse the PBX, the setting never comes into play. To confirm this, you can take a look at the CDR records and see if there is a call that you can identify. If not there, then the PBX was not a part of the issue. This setting is to qualify the IP and addresses that are allowed to register and make calls through the PBX. I do not believe that the calls you are after ever saw the PBX, but were direct calls to the phones. 

   The issue that you may have seen when you thought that the two IPs associated to the same extension were causing havoc might be:

  When the phone registered, the PBX responded to the port and IP of registration. This would have been the Public IP and port as seen, but the contact header would reflect the private IP. When subsequent messaging arrived such as perhaps a re-INVITE, the system started to message back to the contact header rather than the seen port and IP and as a  result, the phone is no longer seeing the messaging as the message is going to an IP at 172.87.XXX.XXX, which is not really you. 

   

  You might be better off taking a look at the security section of the PBX. 

• 0
  
  Jim smith April 18, 2018 16:00

  Thanks Larry.  Quite the answer.  I wish I could use VPN connectivity.  Unfortunately at this time that is not possible as I don't have command and control of their networking.  Hopefully that will happen soon.  Their main office houses accounting and distribution.  All three locations use an online system for project management that is hosted elsewhere, so there is no need for VPN for data reasons.

  The routers do not have issues with routing calls between PBX and phones.  All the necessary ports are open for communication.  There are 25 phones between the three locations.  On the PBX Monitor screen, all phones show the public IP of the office as the registration IP address.  When there has been a breach, a second unknown IP address shows in addition to the correct IP address or it replaces the correct IP address for that extension.  This obviously causes that one extension to go offline at the office and that is when I get a call.  

  The popup info box on Extension Editor says only the IP assigned is allowed to register the extension.  Nothing says this IP cannot be the public IP of the office where the extension is located.  It would seem logical from the info box that this should be sufficient to restrict other IP's from accessing the extension object on the PBX,  

  The final cure yesterday was to destroy the extension 101 object and rebuild it.  Once that was done and the phone rebooted, the phone registered.  I also put the pubic Ip address for the office in the extension restriction as follows: 172.87.142.50 / 255.255.255.255  All is working.

  So what am I missing?

  On my NetSapiens switch, we do a site level IP restriction instead of singular devices.  

   

• 0
  
  Larry Neblett April 18, 2018 16:50

  Keep in mind that if a registration if occurring and shows an unknown IP, then that device has the passwords and authID by which to register. To register, a phone has to make the request and then has to be authenticated by the PBX. 

   

  Is it possible softphone applications are in use such as with Linkus and what you are seeing is indeed a valid attempt for a register? This would then be dependent upon the number of concurrent registrations allowed for an extension. If the number is set to 1, then whichever device registers first gets all the goodies. The IP you posted is hosted by TeraSwitch from the Pittsburg area.

• 0
  
  Jim smith April 18, 2018 17:43

  You correctly identified the external IP as our trunk source.  It is possible that the Linkus app is the secondary IP and that it caused the issue by locking the extension object for some strange reason.  There seem to be some small quirks from time to time that I run across with the S-Series.  I will try to verify that it was a Linkus connection that caused the problem.  Whatever, it is sad that the extension object got corrupted.  Makes me nervous.

• 0
  
  Larry Neblett April 18, 2018 17:56

  If you use added devices for a given extension, then you must increase the number of concurrent registrations accordingly. As stated, if the extension was only set to 1, then whichever device registers and is accepted by the PBX will be the only device that the PBX will use. 

   

  I doubt that it was corrupted, but when you deleted and re-created, the unknown device is no longer able to register as it has old credentials that are no longer valid. The device may now show up in the blocked IP list in the security section of the PBX and then under IP auto defense.

• 0
  
  Jim smith April 18, 2018 18:04

  Ext 101 did have 2 concurrent registrations so it might have been the Linkus registration.  I will find out about the IP associated with where that customer may have used his mobile phone and see if It then shows that way on the monitor page.

  Say the object was not corrupted.  How does one clear the multiple registrations which was apparently causing the object to be locked and not allowing the physical phone to make or receive calls?  All lines were shown as down on the physical phone.

  Continuing on my beef with the phone objects, I just had to delete and rebuild two extensions because they did not register properly.  IP shows, but icon is greyed out.  Rebuilt object, reboot phones and they connect and work.  Customer had attempted multiple reboots including power off.  This kind of thing is unsettling.

   

• 0
  
  Larry Neblett April 18, 2018 18:16

  Again, you need to dig deeper. I have multiple concurrent registrations on a number of extensions and am not having any issues. When you rebuild, I assume a different authID or password is being used and you are having to update the desired phone with same. If using the same, then it could be that the the other phone is now registering first. Reboots might not do anything as nothing had changed as there was still a valid register in place. 

  You may have to do some captures to see what is really going on. I assume that you are using relatively complex passwords so as to deter others who might try.

   

  With regard to the statement, The popup info box on Extension Editor says only the IP assigned is allowed to register the extension.  Nothing says this IP cannot be the public IP of the office where the extension is located.  It would seem logical from the info box that this should be sufficient to restrict other IP's from accessing the extension object on the PBX,   This is what I am advocating, that it should be the public IP when remote and the private only when local. I mistook your initial post by thinking that your were using the 172.87.XXX.XXX as a private IP when you then indicated the 74.113 address. 

• 0
  
  Jim smith April 18, 2018 18:28

  Thanks Larry.  I really like the units.  I have about sworn off hosted services thanks to the S-Series for basic phone service.  This one site is the only one I have remote registrations at.  

  The only extensions I have that has ever shown multiple IP's all have Linkus apps installed.  No other phones in the office.  The ones I had to rebuild this morning were 3 desk phones with 1 session all in the same office.  For some reason, one would register and the BLF's were acting funny and the other two showed IP on the monitor screen but greyed icon.  Rebuild, reboot and BAM!  we are up.  I'm not sure how I would diagnose these issues as I have no way to trap the failure.  I just hear about it when they call me and say they cannot use their phone.

• 0
  
  Larry Neblett April 18, 2018 18:48

  While the phone is not registered, get into the phone web interface and confirm the settings to be correct and unmodified. If so, simply do a reboot of the phone while a capture is running at the PBX. Then after the reboot and allowing some extra time by which you know it should register, stop the capture and see what the messaging is. What you should see is that the phone should send a REGISTER request and the PBX upon seeing same should respond. It is the response that will be of interest. There are only two oprtions:

  1, The PBX never sees the request and therefore does not respond or,

  2. The PBX sees the request and responds with a challenge for authentication in which case the phone will provide the credentials and either be accepted or denied, or it outright rejects the request with an SIP error code from the very start.

• 0
  
  Jim smith April 18, 2018 18:52

  Thanks.  I will setup a test case for this.  The phones giving me issues are in another city.  I'm wondering if internet latency may be causing some of this.

• 0
  
  Larry Neblett April 18, 2018 19:02

  With regard to the registration, probably not. With BLF possibly. It depends on the network reliability and the number of BLF keys or extensions being monitored and the PBX utilization. Each change of status requires a message to be sent and the more there are, the greater the likelihood that the messaging may not get to the destinations in time to reflect the status of a given extension at that exact second. 

• 0
  
  Jim smith April 18, 2018 19:12

  I have a U100 that sometimes will not reflect the correct BLF green/red status on Yeastar T46G phones on a gigabit network and other times it will.  Network traffic is very low with 10 users.  I can watch the phones in one remote office and see the system setting up conversations as the phones set to ring simultaneously almost do.  The same is true for reflecting the BLF settings.  However, what is a bother is that sometimes the BLF buttons will not reflect the status of the other extensions they are monitoring no matter what.  That is the issue.  You know the extension is busy only when you call it as the button does not reflect phone status.  This is also true with my S-Series from time to time.

• 0
  
  Jim smith April 18, 2018 19:26

  One thing that has crossed my mind is to use TLS encryption for the remote extensions.  We have been discussing it but have not tried it to see if it is practical.  Seems that would also provide a good block against intrusion.

• 0
  
  Larry Neblett April 18, 2018 19:27

  BLF is accomplished thru a subscribe and notify method. When an extension is set to monitor (BLF), it sends a message to the PBX that it wants to subscribe to "watch" the desired extension. When the monitored extension changes a status, the PBX then sends a notify to each extension monitoring the extension that a change has occurred. 

  Should a subscribing extension miss the notify, for any reason, there will be no response seen at the PBX and the PBX will assume that the monitoring extension has gone off-line and will make no attempt to resend and may stop sending further notify messages until the extension renews the subscription. The intent is to avoid the possibility of sending countless retries and congesting the network with messages that will never be seen or acknowledged...imagine if the remote site lost its connection. 

• 0
  
  Larry Neblett April 18, 2018 19:54

  To me, the point of TLS is to encrypt the messaging so as to prevent others from intercepting and then being able to know the ports in use and other details that might enable one to listen in. While it may offer some protection, you should consider:

  1. The impact of adding encryption and the added load it entails for the PBX to accommodate. 

  2. If using a SIP provider, then it may be somewhat problematic as very, very few support its use. 

  3. The unusual IP that has shown up, is (so far) a known IP to be that of your main trunk and possibly being used by softphones which does not by itself constitute a intrusion. 

  4. I am uncertain, but do not think Linkus supports TLS.

  4. The other rouge calls that cause a phone to ring can be handled by the other methods mentioned previously. 

  If there is a concern about the security/confidentiality of the messaging, then by all means go for it. Keep in mind that with the added functionality also comes the added complexity when things go awry. What has been relayed so far is observations and assumptions without having yet attempting to diagnose the underlying cause. If it were me, I would try and find out what the existing issues are and their cause and see if they can't be resolved thru conventional means before going down the TLS path. 

• 0
  
  Jim smith April 18, 2018 20:24

  TLS is overhead for sure as any encryption is.  The SIP providers I use mainly do peer-peer with passwords.

  Linkus does not support TLS at this time.

  I am definitely on the hunt for the root cause.  I know I am not there yet.

  As for TLS, I have a handfull of financial, accounting and law firms.  We are encrypted on everything but telephones.  I'm now getting demands to encrypt phone conversations.  I plan to find a SIP provider that will work with me on this issue.  It's like using Office365 and getting guaranteed encryption on your side of the email and letting the other side do what they want.  At least you meet the demands placed on you by the compliance people.

   

  Thanks for a great conversation Larry.