Control,Kerio,Operator,Security,VOIP
2012/09/29
A customer recently installed a Kerio Operator appliance behind a Kerio Control Firewall. Although his LAN is presently small enough that he could have put Operator and the phones on the same subnet as his computer network, he expects to grow, so Operator was put on a separate internal network. This avoids some traffic congestion (the firewall is still a choke point, however) and adds some additional security.
However, this does make things more difficult on the firewall configuration. The customer and I had set this up, and things were working, but then what seemed like minor changes were made and incoming audio stopped working. That is, if I called in, I could hear them answer but they could not hear me.
Obviously that wasn't acceptable.
I had to call Kerio to get this fixed. The basic issue was adding a source NAT translation for the outbound rule. Honestly, that confuses me. Yes, I understand source NATting conceptually, but earlier, without that rule, the customer was able to call me and we both could hear each other, and I don't quite understand why.
I found this at NAT and VOIP:
In addition, the way in which conventional VoIP protocols are designed is also posing a problem to VoIP traffic passing through NAT. Conventional VoIP protocols only deal with the signalling of a telephone connection. The audio traffic is handled by another protocol and to make matters worse, the port on which the audio traffic is sent is random. The NAT router may be able to handle the signalling traffic, but it has no way of knowing that the audio traffic is related to the signalling and should hence be passed to the same device the signalling traffic is passed to. As a result, the audio traffic is not translated properly between the address spaces.
OK, so it's like FTP - a new port is opened for audio. But if that's true, why doesn't it need full cone NAT as described at Use of Full Cone Nat in the Control manual - which even uses SIP phones as an example of where you'd need it!
It makes my head hurt. I could probably spend a few days tracing packets and maybe figure it out, but I lack the patience. For stuff like this, I'm willing to let the Kerio techs drive.
Here are some pictures of the basic setup. I've blocked out the public IP address used, but the rest is just internal IP's that are useless to a hacker. What you need to understand is this:
Customer has 5 public IP's, xxx.xxx.xxx.242 to xxx.xxx.xxx.246
The office LAN is 192.168.171.0
An "Other interface" is defined on one port of Control with address 192.168.191.1
Operator is connected to a switch connected that port
The SIP phones are all connected to Operator through the same switch
Operator has the private address 192.168.191.2
Operator uses the public address xxx.xxx.xxx.243 (2d of his public IP's)
Operator has been configured as described. Note that "NAT enabled (Kerio Operator is behind a firewall)" is checked.
The Control side shows the rules as suggested by Kerio. Note that order matters and that two new services were defined: SIP TCP (because the built in rule is only UDP) and RTP, which is defined for the same UDP RTP port range as defined in the Operator setup shown above.
That's it. With this in place, the phones now worked as they should.
Comments: Click Here.
Want to showcase your product to our audience? Check our advertising options.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them.
I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you
to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. If you have any question, please do feel free to contact me.
-
Skills Tests
-
Psst - wanna work for yourself?
-
Unix/Linux Troubleshooting e-book
-
Kerio Mail Server
-
Consulting
-
Advertise Here