SIP protocol operational errata when NAT with PAT is applied
Status: Beta
Brought to you by:
tries
Menu
▾
▴
#45 SIP protocol operational errata when NAT with PAT is applied
I have a situation where my router (a CPE) is not only applying natting to the address space but also the port translation.
In TWINKLE with STUN activated I have an initialization like this:
(note that the client side is asking from udp port 17048 while in SIP messages there is embedded udp port 17026 gave by STUN server)
U 109.xxx.xxx.73:17048 -> 109.xxx.xxx.54:5060
REGISTER sip:sip.server.net SIP/2.0..Via: SIP/2.0/UDP 109.233.81.73:17026;rport;branch=z9hG4bKonfc
zdai..Max-Forwards: 70..To: "diego" <sip:diego@sip.server.net>..From: "diego" <sip:diego@sip.server
.net>;tag=ljpmo..Call-ID: rfupnqijxwdejdh@localhost..CSeq: 135 REGISTER..Contact: <sip:diego@109.
xxx.xxx.73:17026;transport=udp>;expires=3600..Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,SUBSCRIBE,INF
O,MESSAGE..User-Agent: Twinkle/1.4.2..Content-Length: 0....
and siproxd answer to an ERRATA port (17026) and not the real port from wich connection arrived (17048).
U 109.xxx.xxx.54:5060 -> 109.xxx.xxx.73:17026
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 109.xxx.xxx.73:17026;rport;branch=z9hG4bKonfczdai..Record-Route: <sip:si
proxd@109.xxx.xxx.54:5060;lr>..From: "diego" <sip:diego@sip.server.net>;tag=ljpmo..To: "diego" <sip
:diego@sip.server.net>..Call-ID: rfupnqijxwdejdh@localhost..CSeq: 135 REGISTER..Allow: INVITE..All
ow: ACK..Allow: CANCEL..Allow: OPTIONS..Allow: BYE..Allow: REFER..Allow: SUBSCRIBE..Allow: NOTIFY..Allow: IN
FO..User-agent: Asterisk PBX..Supported: replaces..Content-Length: 0....
Obviously it can't work.
If I don't use the STUN server, port information isn't embedded in request but siproxd answer only to port 5060.
It would be useful if siproxd could reconstruct the session based on the SIP network layer.
I read the other bug that you close saying that siproxd is on application layer... but I can't do anything about the poor behaviour of the CPE.
Hi,
First: Do not use any "NAT helpers" with siproxd, they just make things worse. STUN has been invented as a futile attempt to fix things that NAT breaks. Also, ingoring the embedded IP & port information in SIP telegrams and using information retrieved from layer 3&4 instead is basically violating the SIP RFC3261 in an attempt to minimize inpact of NAT (and it's just trying to minimize, it cannot eliminate).
Siproxd tries to avoide NAT issues by:
a) eliminating NAT in the path completely (if running on the NAT firewall) - this is the preferred setup
b) limit the impact of NAT by using a defined port range and setup port forwarding in the NAT router ("in front of NAT router scenario)
local UA ---- siprox d---- NAT router ---- Internet
I *assume* that you are emplying the "in front of NAT router" scenario. PLease check the documentation in chapter 7.3 ("in front of NAT router" scenaio) on how to set-up things correctly. Also note that on the NAT router there *must* be a port forwarding configured.
Siproxd follows the RC3261 and uses the Contact information embedded in the SIP telegram and does not try to guess things from IP/UDP layer information - nd if no specific port information is supplied in the contact header the default port is 5060.
From your description it is not obvious to me how your setup actually looks like. looking at your IP addresses (109.x.x.x - public IPs) it might even be that you are trying to work around some far-side NAT issues. Siproxd definitely can not fix NAT issues that are caused by a NAT router on the remote side.
Can you provide a more detailed description of your setup like a short ASCII drawing
local UA ---- siprox d---- NAT router ---- Internet
and where you have taken the capture.
The capture has been taken on the public interface of the gateway/router where siproxd is running. I extracted the first ask coming from the UA and the first response from siproxd.
Twinkle, that I think is very useful to debugging SIP when comes on the (UA side), says "You are behind a symmetric NAT.\nSTUN will not work.\nConfigure a public IP address in the user profile\nand create the following static bindings (UDP) in your NAT."
and give the correct ports interval to map RTP and signaling but I can't do anything on the CPE NAT stack! (Siemens/SAGEM Gigabit SE680)
Here it is my drawing:
| local UA +--+ NAT CPE +--INTERNET--+SIPROXD/NAT GATEWAY+--+LOCAL ASTERISK|
I think should be a classic siproxd implementation.
in other words:
local user agent have a private ip and uses a gateway (CPE) to reach via internet siproxd.
siproxd is installed on a server that have a public ip and act also as gateway doing natting for the local asterisk.
asterisk can communicate directly to siproxd without any natting on the local interface.
For the other considerations, I understand the architecture, but without having siproxd using details from the udp connection it is impossible to make it do the right work with this kind of weird natting.
Hi,
> I think should be a classic siproxd implementation. in other words:
> local user agent have a private ip and uses a gateway (CPE) to reach via
> internet siproxd.
Wrong. The local UAC (Client) must make use of siproxd to reach the Internet. If the SIP traffic first pases a NAT router (and is messed up) siproxd will not handle the situation.
> siproxd is installed on a server that have a public ip and act also as
> gateway doing natting for the local asterisk.
Wrong. Siproxd does help to masquerade *local* UACs (Clients) but does not work on the server (REGISTRAR) side. Siproxd does not support "far side NAT traversal".
The supported "in front of NAT router" scenario is (observe the order of the devices):
local UAC --- siproxd --- NAT --- INTERNET --- REGISTRAR (UAS)
You on the other hand try to use siproxd to fix things after they have been broken (by your NAT/CPE router). This does simply not work with siproxd - others have tried and failed before, trust me. The scenarios mentioned in the documentation are supported and work. Most other things do not work at all or just partially.
First:
Siproxd must be placed between the local UAC (private IP range, siproxd "inbound" network interface) and the public Internet (siproxd "outbound" network interface). Siproxd is designed to operate completely on the UAC side.
Second:
Siproxd can not help a SIP server (REGISTRAR) with NAT issues. SIP VoIP providers use different technologies trying to fix NAT issues on their REGISTRAR side, and those technologies usually involve a quite some guesswork.
The above two restrictions are by design of siproxd and will not be changed.
Your should:
- Have the Asterisk box directly connected to the Internet (NAT on the REGISTRAR side is tricky)
- If you want to use siproxd on the local UA side (between local UA and local NAT router) you must be able to configure port forwarding for specific ports on the local NAT router.
If those items are not an option, you might consider using VPN technology to deploy a "NAT clean" network segment between the two locations and allow SIP/RTP traffic.