None, NATPass™ is optimized for best performance therefore almost 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. NATPass™ can be integrated with Linux firewall, in that case IP Tables needs to be installed as well. Few Linux core libraries are also used.
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.
NATPass™ is build for Linux only and can run in most linux distributions. The preferred distributions today are Centos, Fedora, Ubuntu and Red-hat.
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.
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.
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 supports only UDP. But TCP support is on the roadmap.
NATPass™ binds with only one network interface and one IP address. 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. Outdated or proprietary protocols are not supported.
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
However you don't have to worry about that, with NATPass™, it does not mater what type of firewall or NAT 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 if you are familiar with configuring SIP devices to work behind NA, If your PHONE supports STUN, and if your NAT is not Symmetric. Many times you would need to configure the Remote firewall with some port forward rules. STUN can be problematic when there is multiple IP phones behind the router, some extreme cases require forcing IP phone's source port to be unique in same LAN.
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 by NATPass only when needed.
The ports used are configurable. You can use a less known port to hide your application and reduce network scan hits. For SIP signaling it uses 5 ports: the base port configured and the four consecutive ports. All devices should be configured to connect to the base port. Regarding media ports or RTP ports, the range is configured, the number of ports in the range must be at least twice the number of concurrent calls you plan to have.
Yes, Media relay is called Full Mode and can be configure per domain or per SIP extension. You can have some customer in Full Mode and others with Media relay or Media Path Optimization.
Yes and Yes, you can achieve redundancy by using DNS SRV records. Also in NATPass™ you can configure redundant entries for your IPPBX or Registrar/SIP server. It can be used for failover or load balancing.
i.e there are two SIP servers sitting on different physical servers in the network. Wnat NAT PASS to send say 50 % calls to server A and 50 % calls to Server B.
In the natpass.cfg file you add the modifier SRV to the domain. Endpoints should register to a domain.
SRV Modifier will make Natpass look inside the config file for server entry to resolve where to forward those requests in that case DNS is not used for that domain for Invite and Register requests.
The settings below is an example in which natpass will load balance traffic for endpoints registering to xxx.testing.conm between .5 and .6 For yyy.testing.com it will always send to .5
domain = xxx.testing.com SRV
domain = yyy.testing.com SRV
server = xxx.testing.com 50 192.168.201.5:5060
server = xxx.testing.com 50 192.168.201.6:5060
server = yyy.testing.com 100 192.168.201.5:5060
*Disclaimer: The listed Interop Tested Products have been tested by NATPass™. However, we cannot certify that all models will work in each environment. It may depend on different versions, models, and network design. Products should be checked for every environment.
How to find out current registered contacts or phones
There is built in scripts that can be run from linux console.
The output is a list of all contacts and a summary of current registered devices and active sessions.
Please notice that If your natpass.log file is too large (more than 1 GB) and depending on traffic and memory size on your server this command might not execute.
How do I restart Natpass and verify the my natpass license size?
Natpass should be configured to autostart with the server however if there is need to stop/start the service manually the following commands can be used thru Linux console:
( the # is the linux console prompt)
# /usr/local/natpass/bin/natpass_ctl stop
# /usr/local/natpass/bin/natpass_ctl start
After restarting Natpass the license size can be verified with the following command:
# grep "users version" /usr/local/natpass/logs/natpass.log
An example output for a 500 endpoints license is:
Introduced in version 3.6
This is how you configure if Natpass is on a Private IP.
If your natpass is on a private IP, first make sure SIP and RTP ports are forwarded to NATPASS internal IP.
In the configuration file natpass.cfg:
Define the external public IP. This IP is used to license Natpass and needs to be mapped to server internal IP. ipaddr = xxx.xxx.xxx.xxx
Define the internal IP on the server. Natpass will bind to private_ipaddr = yyy.yyy.yyy.yyy
There is also an optional parameter to configure if all your PBXs/SIP Registrar servers are in same segment/subnet as natpass or reachable (without NAT) using internal natpass IP.
Define the Natpass IP to be used to reach the PBX (same value a private_ipaddr) server_ipaddr = yyy.yyy.yyy.yyy
If your PBXs/SIP Registrar servers are reachable thru public IP, do not specify this parameter: server_ipaddr .
This is how you configure if Natpass is directly running a public IP.
In the configuration file natpass.cfg:
Define server's public IP. This IP is used to license Natpass.
ipaddr = xxx.xxx.xxx.xxx
Make sure to Comment out or remove the following parameters
#private_ipaddr = yyy.yyy.yyy.yyy
#server_ipaddr = yyy.yyy.yyy.yyy
Version 3.7 introduced a new feature called Quiet Mode.
This setting is designed to make the task of network scanners harder. By default NatPass responds to all SIP requests (when sender is not in black DDOS list). Scanners will send rogue SIP packets and if found response they know there is a live SIP server there which prompts more attempts and brute force attacks.
When quiet_mode = yes Natpass does not respond and quietly drop rogue SIP requests sent with any domain not defined in the configuration file.
New version 3.7 includes a new setting for the configuration file to correct this.
Some PBX vendors use CSTA encapsulated in SIP messages to signal status change like DND between phone and PBX.
A SIP endpoint can lose network suddenly. By default natpass checks for RTP in all INVITE dialogs in case a client stops sending RTPs with out proper call disconnection signaling so it can disconnect the call.
This causes a problem because natpass would close the dialong carrying CSTA updates in which is normal that no RTP is transmitted.
If you have this scenario add the following to the configuration file:
check_rtp_flow = false
Can I restrict Natpass to work with specific SIP Domains and device SIP User Agent
Domain should be defined with the keyword 'RSTS':
domain = *.mymsp.com RSTR FULL PRSN
domain = pbxn.othermsp.com RSTR FULL PRSN
For those domains, Natpass will only allow connections from SIP client that present the correct User Agent headers (User-Agent:) definedin the "broken" section with Y modifier.
Y means Yes pass traffic for this User-Agent even if is for a restricted domain.
broken = Y Cisco
broken = Y Yealink
broken = YAIsT Polycom
broken = YE Grandstream
broken = YD Grandstream HT-5
broken = Y Fanvil
Matching of UserAgent: Max length first.
For example by specifying those two lines you can prohibit one particular "Telco" User-Agent and allow all other:
broken = Y Telco
broken = - Telco Systems AC-211