Tcpbind And Source IP Address

Home » Asterisk Users » Tcpbind And Source IP Address
Asterisk Users 17 Comments

I am running asterisk 13.1.0 on Ubuntu server 16.04. There are two IP addresses from the same subnet set on one interface, and bindaddr is set to the second on them in sip.conf and in iax.conf. Incoming connections work as expected. However, for outgoing connections it seems that asterisk tells the kernel to use the specific “bind” address only in case of UDP usage (both SIP and IAX work like that). In case of outgoing TCP connections (SIP TCP and TLS) the first IP address from the interface is used. In my understanding, normally ‘bind’ should not only tell on which address to listen, but also which source address to request for outgoing connections, but it works only for UDP connections for some reason. Can anybody explain if it’s a normal behavior?

17 thoughts on - Tcpbind And Source IP Address

  • Hey guys, any thoughts on that? Probably a bug or is it a default behavior?

  • Hi!
    Attached sip.conf and interface config as well. In this case we use only TLS, but I have checked with TCP – same situation, 192.168.0.172 is used as a source. For UDP 192.168.0.177 is used as expected.

    пн, 13 мар. 2017 г. в 2:37, Joshua Colp :

  • Does the output of netstat -a confirm that it is bound to only that IP
    address? If so, then it seems chan_sip has done its part.

  • Yes, look:
    netstat -nlp | egrep ‘506[01]’
    tcp 0 0 192.168.0.177:5061 0.0.0.0:* LISTEN
    13255/asterisk udp 0 0 192.168.0.177:5060 0.0.0.0:*
    13255/asterisk Still, the problem is with *outgoing* *TCP* packets originated from asterisk. Source IP is set to the first IP address of the interface only when TCP is used. As I understand, the application (chan_sip in this case)
    should request kernel to use the specific source IP address (used in bind directive) for outgoing packets, however it seems to be done only for UDP. For outgoing packets on TCP/5061 I see the following:
    IP *192.168.0.172*.47596 > .5061: Flags [S], seq 2529313754, win
    29200, options [mss 1460,sackOK,TS val 82765588 ecr 0,nop,wscale 7], length
    0
    And with UDP as transport:
    IP *192.168.0.177*.5060 >     .5060: SIP: OPTIONS ….

    пн, 13 мар. 2017 г. в 13:55, Joshua Colp :

  • The underlying code does this already. It connects using the bound socket (which would be bound to the IP address you’ve provided). This should have the system use the source IP address as you want, but it’s evidently not.

  • Mmh sorry I’m afraid I did not understand your last message. Yes the code does that but only with UDP, for TCP the source address is 192.168.0.172
    though it’s bound to 192.168.0.177:
    IP 192.168.0.172.47596 > .5061
    If it was a system/kernel issue, then why is the behavior different for TCP
    and UDP? I thought that maybe the application does not request the bound address as a source in case of TCP…

    пн, 13 мар. 2017 г. в 14:37, Joshua Colp :

  • The chan_sip module, from looking at the code, does use the bound address when connecting. Someone would need to dig deeper to understand if the problem is somehow in Asterisk or if it is the system somehow doing it.

  • Ah ok, thank you for checking. I’ll maybe also try with the latest asterisk and/or other distro and see if this behavior is reproduced.

    пн, 13 мар. 2017 г. в 14:46, Joshua Colp :

  • Tested with latest Asterisk 14.3.0 on Ubuntu 16 kernel 4.4.0-66-generic and CentOS 7 kernel 3.10.0-514.10.2.el7.x86_64. Absolutely the same behavior. Joshua, maybe you can advice what can be done further?

    пн, 13 мар. 2017 г. в 14:52, Kseniya Blashchuk :

  • You can file an issue but chan_sip is a community supported module, so there is no guarantee of when it would be looked at and resolved. Ultimately though someone has to spend the time to replicate what is going on, look into the code, and understand what is going on.

  • Ok, thank you for the assistance!

    пн, 13 мар. 2017 г. в 16:38, Joshua Colp :

  • Hi Kseniya,

    You might test with chan_pjsip: We have less production experience with chan_pjsip than chan_sip, however, for now, we are more and more confident in this new stack while we’re digging in documentation and we’re testing on production.

    However, I’ve no idea if you’ll have the same issue with pjsip, but more chances of support on the issues tracker of Asterisk to have help.

    Regards.

  • Hi!

    Unfortunately pjsip is broken in Ubuntu Asterisk installed from repo. Yes I
    also thought to try with pjsip, just to know if it’s also affected. I’ll try to make a test next days.

  • Hi,

    I recommend you to install from sources, especially because the latest Asterisk 13 has several bugfixes for pjsip. To my knowledge, nobody proposes ppa or Debian backports for Asterisk.

    Wazo has Debian packages, but it’s only for Debian Jessie and with extra patches for Wazo.

  • Hi!
    The issue did not reproduce with pjsip. As for ppa – somebody recommended me ppa:sapian/asterisk. Does anybody use it maybe?

    вт, 18 апр. 2017 г. в 2:24, Ludovic Gasc :