Natpass is licensed according to number of registered devices. The number of channels or concurrent calls from those registered devices is not limited. Licenses are generated based on the IP address of the server running the application. If the IP address is changed the apllication would become unlicensed, to avoid that, a new license would have to be issued (processing fee might apply).

No. It uses some SIP specific features to traverse through NAT/Firewall and only your SIP PHONE can use it. It does not compromise your network.

That is part of the unique algorithm from NATPass™. It basically discovers what kind of NAT it is dealing with for each call and makes use of SIP signaling options (183 session progress; re-invite) to redirect media stream to pinhole opened by current session in remote firewalls.

NATPass™ is build for Linux only and can run in most linux distributions. The preferred distributions today are Centos, Fedora, Ubuntu and Red-hat.

It is a matter of downloading the missing libraries for the distribution used, usually available on line. Many customers run NATPass™ on pretty much any Linux distribution. Please download the installation guide that include details on how to install missing libraries.

None, NATPass™ is optimized for best performance therefore all logic needed is built-in. In fact, it is best not having “by default” services like Apache, php, mysql, xinetd running in the server. In some cases DNS cache service is recommended but not required. If NATPass™ monitoring module is going to be installed in the same hardware, Apache would be required.

No. It supports only UDP. But TCP support is on the roadmap.

Only one network interface and IP address is needed. However you have the option of configuring a second interface/IP address that is used by the application to discover more efficiently what kind of NAT is the remote SIP device connecting from.

Yes, NATPass™ does not require one of the endpoints on a public IP address. RTP or media stream will flow directly between endpoints in almost all cases except when one of the devices is behind a symmetric NAT (see question about symmetric NAT)

No. It supports only SIP.

Any SIP compliant (rfc 3261) device should work fine. They must support Outbound Proxy. Refer to NATPass™ web site for a list of Interop tested manufacturers.

Yes and Yes, NATPass™ is a software solution however our partners can provide pre-loaded 2U or 4U servers.

It should work with any type of firewall including Symmetric NAT. Symmetric NAT is performed only by advanced enterprise routers, in that case NATPass™ will recognize this scenario and will make the call succeed by signaling and doing RTP bridging. It is all transparent for the user and there is no need to reconfigure anything.

You can find classification of NAT in RFC 3489 – STUN

http://www.faqs.org/rfcs/rfc3489.html. It should not mater what type of firewall you have.

NATPass™ and any other VoIP SBC or nat traversal solution can’t traverse advanced firewalls where explicit rules for blocking VoIP ports/service have been configured. This is unlikely to happen for residential/SOHO users and most enterprises.

They are two different solutions. STUN is less universal. NATPass™ works in many more situations where STUN alone does not work. STUN will not work if you are working behind new symmetric NAT routers. You can use STUN alone if you are familiar with configuring SIP devices to work behind NAT, if your PHONE supports STUN or if your NAT is not Symmetric.

Yes, Video calls work. And in many cases all media stream is released however there are some not mature video phone implementations that might require some modification in order to having NATPass™ releasing video media stream. Anyhow video calls work and media will be automatically bridged only when strictly needed.

The ports used are configurable. For SIP signaling it uses 5 ports: the base port configured the four consecutive ports. All devices should be configured to use base port. Regarding media ports or RTP ports a range is configured, the number of ports in the range must be at least twice the number of concurrent calls you plan to have.

Configure the endpoint to use base port (as defined on configuration file) + 4. I.e. if NATPass™ base port is 5065, it will also open port 5069 for full mode connections.

Yes and Yes, there are two ways to achieve redundancy DNS SRV records and Virtual IP – High Availability. Both are supported by NATPass™ allowing redundant or active-standby type of proxy servers. When configuring high availability NATPass™ application can run on an active server and automatically switch over to a standby server when the main one fails.

You can either fill out our contact form and specify your question there or contact one of our partners directly.

Value: 

• "off" - Disables Denial of Service protection.
• "logonly' - Only detect suspicious activity, but not try to prevent it.
• "local" - Use internal (into natpass application) tables to store all suspects and block them - prevent accepting messages from them.
• "system" - use installed and running linux  'iptables' service in the system to block attackers.

All config parameters "sysfw_..."  are used only when dos_level set to "system"

Other considerations:
"local" - would result more CPU load, but not required external service to run.

"system" - much more effective. All unwanted messages blocked by kernel with close to zero CPU power requirement. It may also protect other parts of your system (not only Natpass itself).
Because it invokes external scripts (defined by sysfw_.. params) you can specify exactly what action should be taken but requieres advanced knowledge of Ip tables.

There are 5 parameters configured for "dos_interval":

• "interval" - number of second, duration of one interval. Default: 5 sec

• "time_to_block"  - number of second to hold particular source blocked (if it's considered as a DOS attacker). Default: 300 sec

• "lite_threshold" - (see faq for definition of lite attack) Number or lite messages arrived from the same source within one interval (5 sec) to trigger that source as an attacker. Default: 100

• "heavy_threshold" - (See faq for definition on heavy attack). Number or heavy messages arrived from the same source within one interval to trigger that source as an attacker. Default: 50

• "rtp_threshold" - number of UDP messages (regardless of is it valid RTP message or not) arrived to clients' RTP ports from unexpected source to trigger that source as an attacker. Default: 2000.

• Lite - message arrived to SIP port and was not accepted by Natpass itself.

There maybe different reason of not accepting it, like malformed message that cannot be parsed correctly (or maybe just garbage and not SIP message at all), message could be parsed correctly but sent to unknown domain and so on. 
The key is that Natpass itself makes a decision to reject it - another parts of system are not involved.

• Heavy - SIP message arrived to clients' SIP port, parsed correctly, forwarded to server (Proxy, Registrar) and got back from server negative response 403 (Forbidden) or 404 (Not Found)

dos_multiple = num_of_interv  time_to_block  lite_threshold  heavy_threshold  rtp_threshold

"num_of_interv" - number of single intervals described in param one of dos_interval.
Default: 5  That means 5 intervals for 5 sec each. So it takes 25 sec total to detect slow attackers

"time_to_block"  - number of second to hold particular IP blocked (after it would be considered as a slow DOS attacker) 
Default: 900 sec


"lite_threshold" - Number or lite messages arrived from the same source within N intervals to trigger that source as an attacker.
Default: 200

"heavy_threshold" - Number or heavy messages arrived from the same source within N intervals to trigger that source as an attacker.
Default: 100

"rtp_threshold" - number of UDP messages arrived to clients RTP ports from unexpected source to trigger that source as an attacker.
Default: 5000
Important: if last param in dos_interval set to -1, than last parm in dos_multiple is ignored.


ddos_threshold

Used to detect Distributed denial of service attacks (DDOS). Only Heavy attackers are considered.
Lite attackers could be blocked by "system" prevention type at almost zero cost.

ddos_treshold = heavy_sourceIP_numbers  time_to_block

"heavy_sourceIP_numbers" - number of detected different "heavy" attackers.
Default: 50

"time_to_block" - time (in sec) to set DDOS shield. (see next faq)

Concept of "throttling". That is number of New Registration request Per Second allowed to bypass Natpass from client toward server (Registrar)

throttling = Regular UnderDDOS

• "Regular" - Number of new Registration per sec allowed when DDOS Shield is not set. Default: 0. Value: 0 means that throttling is turned Off, and there is no limitation.
• "UnderDDOS" - Number of new Registration per sec allowed when DDOS Shield is set. Default: 20 Important. If that value set to -1, than No New Registration allowed at all.

Natpass requires every device to reregister every 30 sec (by default) in order to hold pinhole in clients firewall open. Let assume we have 100 thousands active devices. In regular circumstances when all registrations distributed evenly in time and every device has 3600 sec (1 hour - default in SIP) registration period, Natpass would bypass to Registrar about (100000/3600=27.77) ~30 registration per sec.

In case of recovery after network outage, box crashes, or Natpass was just restarted, all 100K devices would try to re-register within 30 sec. and that is (100000/30=3333.33) more that 3 thousand Registrations per sec bypassed to Registrar, which is in two orders of magnitude more that regular rate. Registrar may be not powerful enough to handle that traffic and could crashes itself. That is described as "Avalanche Restart" effect in RFC 5390 - Requirements for Management of Overload in SIP That the reason why it may sense to set first param of "throttling=" to not zero value. That would prevent Avalanche Restart effect even when there is no DDOS attack. In production system a value of 200 is recommended, even the Registrar can handle much bigger load.</p></p> <p>Concept of "DDOS Shield"<p>When DDOS shield is not set, any SIP messages (INVITE, OPTIONS, MESSAGE, INFO,...) bypassed from client to server w/o any limitations, regardless of registration status of the client. That maybe that devices didn't receive response for registration yet, but still allowed to place a call.</p> <p>When DDOS shield is set, ONLY registered devices (Registration cached in Natpass) allowed to send anything to server.</p> <p>Second param in "throttling=" specifies how many new registration (from not registered devices) would be allowed to bypass Natpass toward server (Registrar) Default: 20

DDOS shield would never prevent normal SIP call flow from devices that were already registered, but significantly decrease registration attempt from new devices (possible attackers).

Set second param in "throttling=" to -1 would completely prohibit new registration while DDOS shield is set. All existing (already registered) devices may still Re-register w/o any problem. That could have a negative effect, because if legitimate device (not an attacker) lost registration it would never be able to re-register again until DOS Shield is removed.</p> <p>However if there is massive DDOS going on it may sense to have that param set to -1, which would at least protect all current users. That is important to understand that all of described DOS prevention parameters are dynamic and could be changed on fly w/o restart Natpass. Signal SIGHUP sent to Natpass forces it to reread config file.</p> <p>There is one more parameter:</p> <p>dos_whitelist = xxx.xxx.xxx.xxx/mask</p> <p>Example:</p> <p>dos_whitelist = 127.0.0.1/8</p> <p>dos_whitelist = 66.153.122.0/24</p> <p>It specifies network segment which never considered as an attacker. You may specify multiple "dos_whitelist=" lines