[Home]

Summary:ASTERISK-18032: [patch] - IPv6 and IPv4 NAT not working
Reporter:Christoph Timm (timmi)Labels:
Date Opened:2011-06-17 05:56:55Date Closed:2015-04-08 06:55:36
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/IPv6
Versions:1.8.3 Frequency of
Occurrence		Constant
Related
Issues:
is contained byASTERISK-18232 Broken REGISTER sent to IPv4 server when bindaddr=[::]
Environment:AsteriskNOW 1.7.1 CentOS 5.6 Asterisk 1.8.3.3 FreePBX 2.9Attachments:( 0) ast11-go.pcap
( 1) ast11-nogo.pcap
( 2) asterisk.log
( 3) call_from_extern_not_working.cap
( 4) call_from_intern_working.cap
( 5) debug.log
( 6) full.zip
( 7) nat_with_ipv6.diff
( 8) sip_general_additional.conf
Description:Hi All,

I tried to play a little bit with IPv6 to test our VoIP quality software with IPv6 RTP streams.

I add "bindaddr=::" to the general section of the sip.conf and netstat shows that Asterisk is listing also on IPv6.

My Asterisk server is behind a IPv4 NAT and was working absolutely perfect.
But after my bindaddr change I got a problem with external calls.

I spend some time to investigate this issue and found out the outbound calls are working. The externaddr is used in the SIP INVITE.
If I received a inbound call the externaddr isn't used any more in SDP part of the answer from the Asterisk. The result is one way audio. In addition I saw the following message in the Asterisk log:

   [May 25 19:18:18] WARNING[3674] chan_sip.c: Address remapping activated in sip.conf but we're using IPv6, which doesn't need it. Please remove "localnet" and/or "externaddr" settings.



I think that is a bug because the externaddr is used correct during the outbound calls.
Comments:By: Christoph Timm (timmi) 2011-06-17 06:04:04.865-0500

Hi,

I forgot to explane my setup:
ISP <-> NAT<->Asterisk<->Phones
I want to test the IPv6 between Asterisk and phones. On the ISP side it is completly IPv4 with NAT.

I hope this helps.

best regards
Christoph


By: Leif Madsen (lmadsen) 2011-06-17 10:59:37.804-0500

You also forgot to supply console output, full configuration to reproduce the issue, and the SIP trace showing what is wrong ;)
By: Christoph Timm (timmi) 2011-06-19 03:43:27.716-0500

Hi Leif,

sorry for that I'm able to provide the traces and the log but I'm not sure what kind of configuration you need.
I post the configuration of the SIP.CONF which is need for my NAT-

Network Info:
PHONE LAN: 192.168.1.0/24
PHONE in the trace: 192.168.1.153
Asterrsik intern: 192.168.1.5
Asterisk extern DMZ: 172.28.50.10 (Public: 212.126.220.244)
ISP: SIP (213.218.12.2) RTP(195.2.163.100)

I will attach two traces:
1. call from external
from mobile to my extension
This one is not working
2. call from internal
from internal extension to my mobile
This is working

As you can see the Asterisk in using the public IP only in the originated call (INVITE). If the Asterisk received the call it is using the private IP in the answers.

I hope that this information are enough.

best regards
Christoph



By: Leif Madsen (lmadsen) 2011-07-20 12:21:34.164-0500

The console output is what is happening on the console when the call is setup.

Additionally the SIP traces need to be provided from the console in Asterisk not from PCAP in order to know what Asterisk is doing and seeing.

I also think this is a configuration error. It looks like you're double natting, but then you're setting externip outside of the first NAT, but then setting localnet for the 172 network, which I *think* at first glance may be causing an issue.

Honestly I would suggest you check out the asterisk-users mailing list because I have a feeling this could potentially be solved through alternate configuration. It could be a limitation of how FreePBX configures networks, but I'm not sure.
By: Leif Madsen (lmadsen) 2011-08-10 16:20:27.568-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines


By: Jeremy Visser (jeremy23) 2011-09-18 09:30:21.815-0500

Please unsuspend this activity. It has been mentioned on the mailing list a couple of times.

http://lists.digium.com/pipermail/asterisk-users/2010-December/256975.html
http://lists.digium.com/pipermail/asterisk-dev/2011-September/050970.html

In particular, Kevin's feedback:

http://lists.digium.com/pipermail/asterisk-dev/2011-September/050993.html

The main problem is that the code paths that handle the NAT mapping are completely bypassed when bindaddr=::. My simpl(istic) understanding is that this is due to that part of the codebase not having been rewritten to support AF_INET6 structures.
By: Javier Achirica (jav) 2011-11-05 17:23:05.024-0500

I'm also experiencing this bug in version 1.8.7.0 built from sources.

A INVITE example, where it identifies the request as "no NAT" where obviously there's one.

This configuration works fine with bindaddr=0.0.0.0

<--- SIP read from UDP:81.81.81.81:4328 --->
INVITE sip:900000000@server.local SIP/2.0
Via: SIP/2.0/UDP 192.168.1.29:4328;rport;branch=z9hG4bK901496379
From: <sip:user@server.local>;tag=1250711191
To: <sip:900000000@server.local>
Call-ID: 503924960
CSeq: 21 INVITE
Contact: <sip:user@81.81.81.81:4328>
Authorization: Digest username="user", realm="server.local", nonce="42a8deec", uri="sip:900000000@server.local", response="88888888888888888888888888888888", algorithm=MD5
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.4.99.1 (eXosip2/3.3.0)
Subject: Phone call
Content-Length: 319

v=0
o=user 3289 3289 IN IP4 192.168.1.29
s=Talk
c=IN IP4 192.168.1.29
b=AS:128
t=0 0
m=audio 7076 RTP/AVP 111 110 96 3 0 8 101
a=rtpmap:111 speex/16000
a=fmtp:111 vbr=on
a=rtpmap:110 speex/8000
a=fmtp:110 vbr=on
a=rtpmap:96 iLBC/8000
a=fmtp:96 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
<------------->
--- (14 headers 15 lines) ---
Sending to 81.81.81.81:4328 (no NAT)
Using INVITE request as basis request - 503924960
Found peer 'user' for 'user' from 81.81.81.81:4328
 == Using SIP RTP CoS mark 5
Found RTP audio format 111
Found RTP audio format 110
Found RTP audio format 96
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 101
Found audio description format speex for ID 111
Found audio description format speex for ID 110
Found audio description format iLBC for ID 96
Found audio description format telephone-event for ID 101
Capabilities: us - 0x80000008000e (gsm|ulaw|alaw|h263|testlaw), peer - audio=0x20000060e (gsm|ulaw|alaw|speex|speex16|ilbc)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0xe (gsm|ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.1.29:7076
Peer doesn't provide video
Looking for 900000000 in from-sip (domain server.local)
list_route: hop: <sip:user@81.81.81.81:4328>

<--- Transmitting (no NAT) to 81.81.81.81:4328 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.29:4328;branch=z9hG4bK901496379;received=81.81.81.81;rport=4328
From: <sip:user@server.local>;tag=1250711191
To: <sip:900000000@server.local>
Call-ID: 503924960
CSeq: 21 INVITE
Server: Asterisk PBX 1.8.7.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:900000000@79.79.79.79:5060>
Content-Length: 0


By: Valentin Vidić (vvidic) 2015-03-30 03:27:59.055-0500

The patch attached above solves the problem for me on v1.8. The code of this function seems unchanged in v11 and v13 so it might work there also. Please test if you have this issue.
By: Matt Jordan (mjordan) 2015-03-30 07:45:45.959-0500

Sorry we missed that there was feedback on this issue. I'm re-opening, as the code is the same in Asterisk 11.

Two points on the patch/issue:
# Asterisk 1.8 is no longer receiving bug fixes. Please post a patch for Asterisk 11.
# Please do post your patch on review board - I'll comment here with instructions on how to do so.
By: Matt Jordan (mjordan) 2015-03-30 07:47:40.287-0500

Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review [1] instructions on the wiki. Be sure to:
* Verify that your patch conforms to the Coding Guidelines [2]
* Review the Code Review Checklist [3] for common items reviewers will look for
* If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch [4]

When ready, submit your patch and any tests to Review Board [5] for code review.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Code+Review
[2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
[3] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist
[4] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
[5] https://wiki.asterisk.org/wiki/display/AST/Review+Board+Usage


By: Michael L. Young (elguero) 2015-03-30 13:22:53.697-0500

Valentin,

Can you confirm that this is still occurring on 11?  I know we no longer support 1.8, but I am curious which version of 1.8 this is happening on?  This issue is very outdated (last comment was in 2011) and there were NAT cleanups that went into newer versions of 1.8 (in 2013) which also made their way into 11.

Can you update the issue with your latest debugging logs and sip traces?  I am having a hard time figuring out if the patch you attached is the correct solution or not.  This is my first time seeing this issue and I have been running an environment with IPV4 and IPV6 mixed with IPv4 clients behind NAT without any issues for quite some time and I would be curious to test things out properly.

Am I correct in understanding this has to do with NAT-PT being used somewhere?  Is the Asterisk box in an IPv6 only environment?  Or is it in an IPv4 environment?  Is Asterisk behind NAT or is it public facing?  Perhaps a description of the network setup and where Asterisk comes in to the picture would be helpful.

Thanks
By: Valentin Vidić (vvidic) 2015-03-30 17:42:17.525-0500

Original patch was for Debian package 1.8.13.1~dfsg1-3+deb7u3. I've upgraded to a newer version of the Debian package 11.13.1~dfsg-2 but the issue still persists unless the patch is applied.

The setup I have is an asterisk server running behind a NAT for IPv4 and on public addresses for IPv6. Here are the relevant setting from sip.conf:

udpbindaddr=::
localnet=10.0.0.0/255.255.255.0
externhost=cube.dyn.valentin-vidic.from.hr
externrefresh=60

Phones in localnet work without issues. Asterisk external address is 193.198.125.23 and after NAT it becomes 192.168.0.7. Test call is originated from Internet (address 212.15.176.39).

I am attaching a log file (asterisk.log) with the timeout error reported by asterisk and two pcap files with the same call before (ast11-nogo.pcap) and after applying the patch (ast11-go.pcap). In the first pcap file you will find one packet retransmitted several times until the call is finally dropped by asterisk. In the second pcap file internal address 192.168.0.7 is replaced in SDP with 193.198.125.23 and the call proceeds without problems.
By: Michael L. Young (elguero) 2015-03-30 17:56:28.388-0500

Valentin,

What are your NAT settings in sip.conf?

Can you capture a full debug log as outlined here: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks
By: Valentin Vidić (vvidic) 2015-03-30 18:25:31.111-0500

Regarding NAT the settings are:

nat=yes
localnet=10.0.0.0/255.255.255.0
externhost=cube.dyn.valentin-vidic.from.hr
externrefresh=60

I am also attaching a debug.log showing SIP retransmissions and ultimate call failure due to timeout.
By: Michael L. Young (elguero) 2015-03-31 09:43:14.075-0500

It doesn't appear that your issue is related to the original issue that was reported.

I think your problem is with your settings.  You are not telling Asterisk that {{192.168.0.7}} is a local address.  Therefore, it does not do any remapping of {{192.168.0.7}} to {{193.198.125.23}}.  Your patch is just short circuiting the conditional statement and forcing it to always perform remapping.

Please try adding another {{localnet}} setting for the LAN address of your Asterisk box.

{noformat}
localnet=10.0.0.0/255.255.255.0
localnet=192.168.0.7/255.255.255.255
{noformat}

Also, {{nat=yes}} is deprecated.  In 11, the valid settings (which can be combined) are {{force_rport, comedia, auto_force_rport, auto_comedia, no}}.  Since you currently have {{nat=yes}}, then you should change that to {{nat=force_rport,comedia}} in order to have the same behavior as {{nat=yes}}.

I would suggest going through the CHANGES file so you don't have any other surprises with settings in chan_sip or other modules.

Let us know if the above solves your issue.  Thanks.
By: Valentin Vidić (vvidic) 2015-03-31 10:19:56.354-0500

I've updated the nat and localnet setting but it doesn't seem to have any affect. Address {{192.168.0.7}} still appears in SDP and the call eventually fails.

Adding some additional logging shows that the first if condition matches for incoming IPv4 requests when udpbindaddr=::

{noformat}
      if (ast_sockaddr_is_ipv6(&theirs)) {
               ast_log(LOG_NOTICE, "NAT: peer address is ipv6");
               if (localaddr && !ast_sockaddr_isnull(&externaddr) && !ast_sockaddr_is_any(&bindaddr)) {
                       ast_log(LOG_WARNING, "Address remapping activated in sip.conf "
                               "but we're using IPv6, which doesn't need it. Please "
{noformat}

Is this expected behaviour?

{noformat}
[Mar 29 23:42:24] NOTICE[2850] chan_sip.c: NAT: peer address is ipv6
[Mar 29 23:42:24] NOTICE[2850] chan_sip.c: NAT: want_remap is 0
[Mar 29 23:42:24] NOTICE[2850] chan_sip.c: NAT: B peer is 212.15.179.125:5060
{noformat}
By: Valentin Vidić (vvidic) 2015-03-31 10:35:16.485-0500

Also IPv6 addresses don't appear in the debug.log because the {{ast_sockaddr_stringify}} recognizes IPv4 mapping and automatically converts and prints them back as classic IPv4. So no IPv6 appears to be involved but it is happening behind scenes due to IPv6 socket type opened by {{udpbindaddr=::}}
By: Michael L. Young (elguero) 2015-04-07 14:56:51.522-0500

Valentin, thank you for helping me understand things better.  You are indeed correct and I was not realizing what was happening.  Hopefully your patch will get committed soon and thanks for your contribution.
By: Matt Jordan (mjordan) 2015-04-08 06:50:42.352-0500

Merged into 11/13/trunk. Thanks for the patch and the bug fix!