[asterisk-bugs] [Asterisk 0011853]: bindaddr problems

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11853 
====================================================================== 
Reported By:                zenon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11853
Category:                   Channels/chan_sip/General
Reproducibility:            N/A
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-27-2008 18:45 CST
Last Modified:              01-28-2008 20:25 CST
====================================================================== 
Summary:                    bindaddr problems
Description: 
I run asterisk on a machine with six IP addresses not counting loopback,
four public and two private, the latter connecting VPNs. I want SIP on only
one public and one private IP address and absolutely not on the rest. 

As far as I have been able to figure by trial and error (yeay
documentation!), there is no way to tell chan_sip to bind to two addresses;
bindaddr will only accept one single address and can only occur once in
sip.conf. So, since I need SIP on two addresses and must not advertise it
on the other four, using bindaddr=0.0.0.0 and firewalling UDP 5060 on the
remaining addresses seems to be the only solution. 

I have a NAT'ed Linksys PAP2 SIP client that keeps causing problems. It
works just fine with bindaddr=[public SIP address] in sip.conf, but keeps
failing with bindaddr=0.0.0.0. Debugging SIP with bindaddr=0.0.0.0 shows
"Contact: <sip:[account]@[wrong_public_address]>" headers being sent by
asterisk in the "Trying" message of the registration process, followed by
"401 Unauthorized". The wrong public address that is sent is the "real"
public address of the machine, the rest being aliases on the same physical
interface. 

My (uncertain) conclusion is that, if bindaddr=0.0.0.0, asterisk puts the
first address it can find on the machine in the Contact: header of its
response to a registration attempt, thereby causing the client to send
authentication data to the wrong address and authentication to fail. 

If this conclusion is correct, the solution should be easy: don't go
guessing addresses and don't send the Contact: header at all, but just let
the client continue talking to the IP address that it was already talking
to. 


====================================================================== 

---------------------------------------------------------------------- 
 zenon - 01-28-08 20:25  
---------------------------------------------------------------------- 
Found it.

Wnen using 
[general]
bindaddr = 0.0.0.0
externip = 216.207.245.13

the SIP messages correctly use the address declared in externip, but the
UDP packets are sent out on the first available interface that can route to
the destination, which is not the one in externip. That is, if the machine
has addresses 216.207.245.12, 216.207.245.13 and 216.207.245.14, the SIP
messages will be sent out on 216.207.245.12 even if externip is
216.207.245.13. 

At the client end, the firewall as well as the client expect UDP 5060 from
the server's advertised sip address that they have been talking to, so when
the packets arrive from elsewhere, they're simply dropped. This is what's
causing the PAP2 to keep trying over and over again to register without
credentials: it never gets the "401 Unauthorized" responses that asterisk
keeps sending to it.

For a while I feared I might be using a bug report for what could prove to
be a support question, but this is certainly a bug: if a SIP dialogue
becomes asymetric on the network level, with messages coming in on one
address and responses going out on another, nothing will ever work. 

I suspect that all this can be solved much easier by allowing multiple
occurrences of bindaddr, than by trying to track where messages come in and
send replies out on the same address. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-28-08 20:25  zenon          Note Added: 0081307                          
======================================================================