Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Operator » Feature Request (I know i know ... i dont have any votes left though, and this is URGENT)
  •  
nhoague

Messages: 853
Karma: 18
Send a private message to this user
Hi guys ...

Problem 1: Yesterday, I came across a very serious problem. One of our SIP providers main networks were down, and I had to manually admin 18 Operator boxes to change the hostname for the SIP provider to route traffic to a different location. While that doesnt sound too bad, customers were losing their minds that phones were down.

Solution 1: Operator really needs the ability to define multiple provider networks. Even just the same as Control with a semicolon would suffice. Just so in the event one network is down, Operator can fail to another hostname / IP.

Problem 2: After hard coding the IP of the backup network of my SIP provider, phone service was restored. Until the SIP provider got their network working, within a couple hours, then I had to go back into Operator and change the hostname back to original. Now, heres the weird part. Operator for some reason blocked the carrier IPs. So, even after changing hostnames phone service went back down! It wasnt until I called the carrier and they ran a trace and said our PBX was giving them a 403 Access Denied that I looked in security and saw 4 IP's blocked. Sure enough, they were my carriers IP. After removing the block, phone service went right back up.

Solution 2: Operator needs the ability to whitelist IPs. I could whitelist all four of my carrier IPs and never have that potential problem.

Thats all!
  •  
silars

Messages: 429
Karma: 59
Send a private message to this user
For Problem 1, your SIP provider should also look into providing fault tolerance to their system. There are many load balancing schemes that would solve that issue (active-active, active-backup, GSLB, etc.). This is classic Disaster Recover (DR) that all data centers or hosting facilities should engineer.

You could also see if they'll let you maintain two (or more) SIP trunks. One to one location, one to the other. Then, you can set primary/backup as needed and eliminate both problems.
  •  
nhoague

Messages: 853
Karma: 18
Send a private message to this user
While I agree with you that DR should be (and is) the responsibility of the provider, it should also be made available for Operator to have failover as well.

  •  
silars

Messages: 429
Karma: 59
Send a private message to this user
It does offer failover...if you have two or more SIP trunks.

I'd have to disagree with you that Operator should perform the DR functions for a single SIP trunk. That's the ITSP's responsibility, in my opinion.

However, my opinion has little relevance in whether Kerio decides to offer that feature. This is a gray area in terms of how they want Operator to perform. If this is common place for ITSPs to rely on the IP-PBXs to find the next service point, then they will have to add it. If this is the only ITSP that has limited DR capabilities, it probably doesn't make sense to de-prioritize other features.

We'll see how Kerio responds. Smile
  •  
nhoague

Messages: 853
Karma: 18
Send a private message to this user
Yes thats true, I get that.

How about my other idea, Operator should be able to define whitelist IPs?
  •  
Vladimir Toncar (Kerio)

Messages: 1696
Karma: 39
Send a private message to this user
Hi Nick, can you share the name of the SIP provider or send it to me directly?
  •  
Vladimir Toncar (Kerio)

Messages: 1696
Karma: 39
Send a private message to this user
Somewhat related to this, the use of the SIP SRV DNS records by the SIP carrier might help to improve service availability. For example, we have just changed the KB article for Nexvortex, you can now use "nexvortex.com" as the server name instead of "px3.nexvortex.com".
  •  
silars

Messages: 429
Karma: 59
Send a private message to this user
nhoague wrote on Wed, 05 February 2014 19:12
How about my other idea, Operator should be able to define whitelist IPs?


Since this is part of the firewall mechanism, I thought there was already a feature request to add whitelisting/blacklisting to the GUI. I could be mistaken.

It would be an older request. Folks were unhappy that IPs were getting blocked on SIP phones due to password changes, installation, etc. So, instead of blocking after so many attempts, they wanted the ability to set a range of IPs that were never blocked.

This was happening primarily on initial configuration and testing.


  •  
nhoague

Messages: 853
Karma: 18
Send a private message to this user
I have seen where the IP address groups go, but will this whitelist those, even in the event of a malformed SIP traffic? So Operator doesnt ever block those IPs?
  •  
nhoague

Messages: 853
Karma: 18
Send a private message to this user
@Vladimir: I have also just noticed that "nexvortex.com" can be used. And yes we use nexvortex and are otherwise really happy with them! I am going to make that hostname change now.
  •  
silars

Messages: 429
Karma: 59
Send a private message to this user
nhoague wrote on Thu, 06 February 2014 10:48
I have seen where the IP address groups go, but will this whitelist those, even in the event of a malformed SIP traffic? So Operator doesnt ever block those IPs?


I'd have to defer to the Kerio reps. I'm only aware of blocking based on SIP login failures, not malformed SIP traffic.


  •  
nhoague

Messages: 853
Karma: 18
Send a private message to this user
Well it may no be malformed ... maybe a bad use of the word. All I know is Operator blocked my SIP providers IP ... why I dont know, but its that, that I want to whitelist.
  •  
Filip Jenicek (Kerio)

Messages: 1094
Karma: 80
Send a private message to this user
Hi all,

first of all, let me make clear how the blacklisting (security-> blocked IPs) works. Whenever Asterisk receives a SIP packet with an authentication header (usually REGISTER, INVITE, or SUBSCRIBE) and can't find any configured matching peer (extension / sip provider), it will respond with a 403 forbidden. We notice it and basically increment a counter for the particular IP address. When a counter reaches a configured amount, Operator blacklists the IP address. As a result Asterisk no longer receives any requests until the IP is removed or times out.

So a whitelist won't solve any provider issues, because Asterisk will reject the requests any way. For example when a provider sends INVITES from a different/multiple IP addresses, while a provider is disabled, etc.

I admit that a whitelist could come handy to get rid of accidental blacklisting of provisioned phones when you move them from one Operator to another, etc. But how often is that? Btw, while developing Operator, I thought that we are the only ones dealing with this particular use case Smile

Finally, we do have a feature request for a whitelist, only its priority wasn't high enough. Perhaps its time to reconsider. After reading the above, do you still find the feature necessary?

Have a nice day,
Filip
  •  
silars

Messages: 429
Karma: 59
Send a private message to this user
Excellent information, Filip.

Having been around these forums a fair amount, I'd have to vote in favor for some whitelist capability to prevent blocking otherwise important IPs. There always appears to be some new configuration that could benefit.

Obviously, you shouldn't fix the 403 responses, but avoiding the blacklist function would have saved nhoague some work.
nhoague

Messages: 853
Karma: 18
Send a private message to this user
Hey guys,

Filip, yes thanks for the info!

Silars: Thanks for the support Smile

Previous Topic: Error Log full of
Next Topic: Yealink provisioning examples with Alert-Info
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Sat Nov 18 18:58:11 CET 2017

Total time taken to generate the page: 0.00526 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.