Ekiga behind a NAT router
From Ekiga
Getting it to work behind a NAT router
How can I easily use Ekiga behind a NAT/PAT gateway?
Ekiga has extensive and improved NAT support thanks to STUN. In most cases, you do not have any configuration to do, and you can even be reachable from the outside without any port forwarding: just run the Configuration Assistant until the end.
SIP only
The following explanation is valid only for SIP. Please read below for H.323. The first thing to do is to run the Configuration Assistant NAT test:
- If it reports "Symmetric NAT", then you need to reconfigure your router. You will have either to dynamically navigate the router (if it allows it, and a must do if you use Ekiga on several machines), either to forward ports manually to your internal machine. Run Ekiga again, it should report "Cone NAT" or "Port Restricted NAT" and it will work.
Ekiga 2.x only
- If it reports "Cone NAT" or "Port Restricted NAT" you just have to answer "yes" to the dialog asking you to activate STUN support. STUN support will allow Ekiga to place calls over the internet. You do not have to do anything else. You will be reachable from the outside.
H.323 only
For H.323, things are a bit more complex. The first thing to do is to find out your NAT type: for ekiga 3.x, execute:
ekiga -d 4 2>&1 | grep STUN
while for ekiga 2.x, run the Configuration Assistant NAT test.
- If it reports "Cone NAT" or "Port Restricted NAT" you just have to answer "yes" to the dialog asking you to activate STUN support. You many also need to forward a few other TCP ports, see below.
- If it reports "Symmetric NAT", then you will have to manually forward ports 5000 to 5100 to your internal machine. If you want to be reachable from the outside, you will need to forward TCP port 1720 from your router to the internal machine running Ekiga. If you want to be able to do calls with Netmeeting users, you will need to forward TCP ports 30000 to 30010 from the NAT router to the machine running Ekiga. This last step is only necessary when calling H.323 software that does not support H.245 Tunnelling (the H.323 part of Ekiga supports H.245 Tunnelling, forwarding that TCP port range is thus not required when calling them using H.323).
SIP and H.323
- You can apply individually the reasoning for SIP and for H.323. The UDP and TCP ports used by both protocols belong to the same ranges.
- IMPORTANT NOTE: Many VoIP forums report massive problems with some embedded SOHO routers blocking VoIP protocols restrictively and need the built in Firewall turned off (not that bad, You're still behind NAT and mostly protected). Netgear is known to have "very good hardened" firewalls. Ask Manufacturer Support and update Firmware first.
- For good sound quality a router with built in QoS is a must have, "V" type products should have it, older stuff rarer. The best routers to buy are Linux based and have GPL'ed Firmware.
Symmetric NAT: Dynamic navigation of NAT routers
If the Assistant Configuration reports a "symmetric NAT" and you have access to your router configuration, you may try the following.
- The issue
Typical SOHO routers incorporate a Network Address Translator (NAT): local network addresses are hidden behind (translated into) a single address presented to the WAN, which in the domestic case is normally that provided by an ISP.
Normally incoming packets (those from the WAN) are silently dropped unless they match a previous outgoing packet. Apart from reasons of security, the router has no means of determining the destination address on the LAN if there is no match with a previous outward bound packet. This creates a problem in establishing a voip connection between machines which are both behind separate NATs: neither can reach the other to initiate communication even when a sip server has provided each with the other's address.
- Port Forwarding
Such routers normally have facilities for port forwarding: incoming packets for distinguished ports can be directed to a particular machine on the LAN behind the NAT. The limitation is that only the choosen machine can engage in voip calls.
- STUN
The STUN protocol (rfc 3489) is designed to solve this problem, but it does not work with symmetric NATs: those that are strict about incoming packets matching precisely a previous outgoing packet.
- Application Rules: dynamic gateways
Many NAT routers allow Application Rules to be defined which allow specified ports to be opened dynamically to incoming packets when triggered by an outgoing packet. If this trigger is fired when ekiga sends a packet to a STUN server, ports can be opened so that the STUN protocol sees essentially an open NAT: a full CONE. Actually, the trigger rules below just open a restricted range, so this is more accurately a "Port restricted NAT" which is how ekiga may describe the situation once the rules are in place.
That then allows the voip traffic to pass unimpeded.
Example:
- Trigger ports: 3478-3479
- Public ports: 3478-3479,5000-5100
- Protocol: UDP
This rule is shown below on a DLink router:
Another example (Linksys router):
- Trigger port: 3478
- Ports opened (forwarded) : 5000-5100
It is only necessary to trigger on 3478, despite the previous example. For some unexplained reason, this firmware (1.52.15) does not offer a choice of protocols for Port Triggering.
For ekiga 2.x only: Of course, the NAT Transversal Method in ekiga should be set to STUN: this is accessed under the Edit → Preferences → Protocols → Network Settings menu.
I have 2 Ekiga behind a NAT using STUN: they can't communicate
- What is the problem ?
If both clients are located behind the same NAT router (not only the same model, physically the same), clients can't communicate.
- Why ?
When you are using NAT with STUN, STUN will determine what port on the router will be used to route incoming traffic from the outside to your internal client. That way, when an external client sends a SIP PDU on that port, the PDU will be routed to your internal client by the router.
However, in most cases, a router will not accept to route a packet coming from the inside on the external port and route it back inside, it will only accept to route a packet coming from the outside on the external port.
It has been reported it is what happens with IPCop 1.4.15.
- What can I do ?
To solve this you may use Avahi.
I use Ekiga exclusively inside my LAN, how can I disable STUN?
How to disable STUN with Ekiga 3.2.x?
Disable network detection in ekiga should be enable: this is accessed under the
Edit → Preferences → General Settings → Network Settings menu.
How to disable STUN with Ekiga 3.0.x?
Use this command:
gconftool-2 -s /apps/ekiga/general/nat/stun_server --type=string
You can restore the STUN service using this command:
gconftool-2 -s /apps/ekiga/general/nat/stun_server stun.ekiga.net --type=string
How to disable STUN with Ekiga 2?
NAT Transversal Method in ekiga should be disable: this is accessed under the Edit → Preferences → Protocols → Network Settings menu.
I can make calls, but if I let Ekiga running after some time I can't receive any calls
- The problem
If your host isn't behind NAT and is behind a firewall that behaves like NAT except for the address translation magic, this may happend to you:
I've got a simple setup, Linux (Fedora 6), no NAT, a direct connection to the net, but I've got a strict firewall (iptables, stateful). Concerning UDP, only ESTABLISHED,RELATED packets are allowed in, all packets are allowed out. Pretty simple, pretty common, I suppose. The problem is, with this setup Ekiga (as configured by the wizard, with STUN) only receives calls just after connecting to ekiga.net (or any other SIP provider). I can make calls, but if I let Ekiga running after some time I can't receive any calls.
- Why this ?
Ekiga registers with a service using UDP and the service expects to find Ekiga at the port it sent the registration. Well, in Linux with IP iptables, this port is only accessible for 180 seconds after the registration. After this time, the firewall will block the packets coming from the SIP service, as it considers the "session" to be over.
- There are two ways of coping with that:
- If you don't have control of your host, you can configure each account to refresh the registration every 180 seconds.
- If you can control your host (root), you can set the UDP iptables timeout to one hour:
# echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout # echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
See http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN730 for more details. You can use the sysctl utility to set kernel variables more easily.
I have many Ekiga clients on my LAN. Is there a better way than STUN?
If you are using SIP, yes. You can use SIPROXD from http://siproxd.sourceforge.net as outbound proxy.
If you're connecting Ekiga against a local Sip-Gateway (like an asterisk with an e1 line) and don't want it to talk to the outside world directly, STUN may get in your way. Symptoms here are that you might not be able to hear inbound callers from the local network. If you enable debugging or use http://wireshark.org to track your Ekiga, you might find it anouncing your public ip address to your communication partner. Then you need to disable STUN which currently is not configurable through the Interface after the initial setup anymore.
My router prevents Ekiga from working correctly, what can I do?
Please make sure you have read this FAQ correctly because it should work in all cases. The worst case is when you have to forward ports. If you can not forward ports, or if you do not want to do it, you have alternative solutions. For SIP, you can use SIPROXD as outbound proxy. For H.323, please configure the GNU Gatekeeper as a proxy.
Using Ekiga through a http proxy
When connected to a very restricted network such as a university or a corporate network where usually only 80, 443 and 8080 ports are accessible through a https proxy, a SIP client such as Ekiga just can't work.
In such a case you can tunnel the SIP signaling & RTP via http. If you don't have access to such a service, you can use the free service from realTunnel which is known to work.(proprietary solution, binary-only program):
http://www.paradial.com/download/realtunnel-nat-sip-traversal.html
