7 Apr
2020
7 Apr
'20
3:49 p.m.
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please
use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on
sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask
on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the
developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Follow-up to previous closed PR https://github.com/kamailio/kamailio/pull/1488
Had a chance to catch a live call involving rfc7335 private IPs.
It seems like either nat_uac_test() or more likely fix_nated_sdp() doesn't catch the
192.0.0.0/29 subnet as private.
### Troubleshooting
#### Reproduction
route[NATMANAGE] {
...
if (nat_uac_test("8"))
fix_nated_sdp("15");
...
}
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them
next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save
in a pcap file, then add them next, or attach to issue, or provide a link to download them
(e.g., to a pastebin site).
-->
```
U 2020/04/07 10:36:02.572802 135.19.155.163:17669 -> 65.39.1.1:5060
INVITE sip:8007777777@client.mydomain.net:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.0.254:11198;branch=z9hG4bK1066155396
From: "ME" sip:2213@client.mydomain.net:5060;tag=3901872054
To: sip:8007777777@client.mydomain.net:5060
Call-ID: 6_327133011(a)192.168.0.78
CSeq: 1 INVITE
Contact: sip:2213@192.0.0.254:11198
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER,
PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T46S 66.84.0.10
Allow-Events: talk,hold,conference,refer,check-sync
Supported: replaces
Content-Length: 305
v=0
o=- 22668 22668 IN IP4 192.168.0.78
s=SDP data
c=IN IP4 192.0.0.254
t=0 0
m=audio 22936 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
U 2020/04/07 10:36:02.573384 65.39.1.1:5060 -> 135.19.155.163:17669
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.0.0.254:11198;branch=z9hG4bK1066155396;rport=17669;received=135.19.155.163
From: "ME" sip:2213@client.mydomain.net:5060;tag=3901872054
To: sip:8007777777@client.mydomain.net:5060
Call-ID: 6_327133011(a)192.168.0.78
CSeq: 1 INVITE
Server: NXO
Content-Length: 0
U 2020/04/07 10:36:02.573608 65.39.1.1:5060 -> 66.199.2.2:5060
INVITE sip:8007777777@client.mydomain.net:5060 SIP/2.0
Record-Route: sip:65.39.1.1;lr;did=faf.517
Via: SIP/2.0/UDP 65.39.1.1;branch=z9hG4bK6ef8.b9248afe5375fc379eb33718de1f7481.0
Via: SIP/2.0/UDP
192.0.0.254:11198;rport=17669;received=135.19.155.163;branch=z9hG4bK1066155396
From: "ME" sip:2213@client.mydomain.net:5060;tag=3901872054
To: sip:8007777777@client.mydomain.net:5060
Call-ID: 6_327133011(a)192.168.0.78
CSeq: 1 INVITE
Contact: sip:2213@192.0.0.254:11198;alias=135.19.155.163~17669~1
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER,
PUBLISH, UPDATE, MESSAGE
Max-Forwards: 69
Allow-Events: talk,hold,conference,refer,check-sync
Supported: replaces
Content-Length: 281
..
v=0.
o=- 22668 22668 IN IP4 192.168.0.78
s=SDP data.
c=IN IP4 192.0.0.254
t=0 0
m=audio 22936 RTP/AVP 9 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull
request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.1.10 (x86_64/linux) cfcfd5
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC,
DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535,
DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: cfcfd5
compiled on 21:57:38 Feb 12 2020 with gcc 4.9.2
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04,
CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
Debian 8
Linux proxy1 2.6.32-39-pve #1 SMP Fri May 8 11:27:35 CEST 2015 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277
7 Apr
7 Apr
4:49 p.m.
Thanks for the report. Just briefly looked into the RFC, is the net 192.0.0.0/29 not
defined as:
192.0.0.1 - 192.0.0.6 ? I failed to find this IPs in your trace.
There is code in nathelper for this net:
{"192.0.0.0", 0, 0xffffffffu << 3}, /* rfc7335 - IPv4 Service
Continuity Prefix */
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-610499562
5:17 p.m.
@henningw you're right, I incorrectly assumed 192.0.0.0/24 subnet. IP was 192.0.0.254
While on this topic, does it mean 192.0.0.0/24 isn't a private net to be included in
NATed check?
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-speci…
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-610509232
7:06 p.m.
This network is allocated to be used from IETF only. So I don't think it should be
detected from a NAT check, it is not meant to be used as a source or destination.
+----------------------+---------------------------------+
| Attribute | Value |
+----------------------+---------------------------------+
| Address Block | 192.0.0.0/24 [2] |
| Name | IETF Protocol Assignments |
| RFC | Section 2.1 of this document |
| Allocation Date | January 2010 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+---------------------------------+
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-610566831
7:06 p.m.
Closed #2277.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#event-3211231777
8:51 p.m.
@henningw - I am not sure how to deal correctly in this case. But I would rather consider
it a natted source is if is reserved for special purposes, or, in other words, not
allocated for direct IP routing over Internet.
`192.0.0.0/29`, which is subset of `192.0.0.0/24`, is allocated for dual-stack lite, so it
is considered a natted address.
Even such address it is supposed not be used, apparently it is because @zeusca got traffic
with headers using an IP from the range. Could be a misconfigured router or network, but
if the traffic is from residential users, it can be hard to ask them to fix it. Without
treating it as nat, calls will fail to connect properly.
Maybe an option is to add a modparam to control if one wants to match also against
"reserved ranges of addresses", besides what is listed now in the array
`nets_1918` inside nathelper module.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-610613715
8 Apr
8 Apr
6:09 a.m.
@mincona It is indeed a strange case. I could be of course added as as module parameter,
e.g. by a pull request. I thought it is not a bug, therefore I closed this issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-610770156
6:39 a.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
Edited the title to reflect it is about `/24` and added feature request by reopening it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-610779845
6:40 a.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
Reopened #2277.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#event-3212725554
16 Apr
16 Apr
10:02 a.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
It should be supported now in the master branch (related commit reference above).
I set it on by default, because a reserved network address is not supposed to be directly
routable currently. It can be changed by the new `nat_addr_mode`. If someone considers it
is better to be off, I am fine with that as well.
I am closing this issue, can be reopen should be something more to be addressed here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-614548002
10:02 a.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
Closed #2277.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#event-3239147173
10:17 a.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
Thanks Daniel - fine with me to have it activated by default. But good to have it
configurable if in the future it changes again.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-614555647
2:57 p.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
Thinking that this could be eligible to be backported, provided that @zeusca can test and
confirm it works fine.
Otherwise stable deployments might not get calls properly connected by not detecting this
kind of a non-routable address. Personally I haven't faced such case, so I am fine
either way.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-614705584
7:17 p.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
I could test it, have a couple of active endpoints that use those kind of private IPs, but
only if the new feature was to be backported to 5.1 branch which our production runs on,
not ready to upgrade at this time
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-614845610
17 Apr
17 Apr
1:01 a.m.
New subject: [kamailio/kamailio] Support for 192.0.0.0/24 as NATed source (follow-up) (#2277)
I lied.
In a dev environment using master branch, `c=` IP address is now fixed with
`nat_addr_mode=1`
Also tested with `nat_addr_mode=0` and it does NOT change it, as expected.
Looks good to me!
kamailio -V
version: kamailio 5.4.0-dev4 (x86_64/linux) c68d78
Was able to test only in a 200 OK reply:
```
U 2020/04/16 20:40:45.214751 135.19.1.1:19748 -> 65.39.1.1:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 65.39.1.1;branch=z9hG4bK852b.2ac5eb86a9cb2654d292b458b696d7f8.0
Via: SIP/2.0/UDP 65.39.2.2:5060;rport=5060;branch=z9hG4bK3c0a4a1c
Record-Route: <sip:65.39.1.1;lr;did=a83.2a9>
From: <sip:18007777777@client.mydomain.net>;tag=as57291cce
To: <sip:227@135.19.1.1:19748>;tag=224264919
Call-ID: 5788a5ee63e6e659248655176e70aad3(a)client.mydomain.net
CSeq: 102 INVITE
Contact: <sip:227@192.0.0.254:11172>
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER,
PUBLISH, UPDATE, MESSAGE
User-Agent: Yealink SIP-T40G 76.84.0.10
Allow-Events: talk,hold,conference,refer,check-sync
Supported: timer
Content-Length: 320
v=0
o=- 20356 20356 IN IP4 192.168.0.84
s=SDP data
c=IN IP4 192.0.0.254
t=0 0
m=audio 10447 RTP/AVP 107 101
a=rtpmap:107 opus/48000/2
a=fmtp:107 sprop-maxcapturerate=16000; maxaveragebitrate=20000; maxplaybackrate=48000;
useinbandfec=1
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
U 2020/04/16 20:40:45.221758 65.39.1.1:5060 -> 65.39.2.2:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 65.39.2.2:5060;rport=5060;branch=z9hG4bK3c0a4a1c
Record-Route: <sip:65.39.1.1;lr;did=a83.2a9>
From: <sip:18007777777@client.mydomain.net>;tag=as57291cce
To: <sip:227@135.19.1.1:19748>;tag=224264919
Call-ID: 5788a5ee63e6e659248655176e70aad3(a)client.mydomain.net
CSeq: 102 INVITE
Contact: <sip:227@192.0.0.254:11172;alias=135.19.1.1~19748~1>
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER,
PUBLISH, UPDATE, MESSAGE
Allow-Events: talk,hold,conference,refer,check-sync
Supported: timer
Content-Length: 416
v=0
o=- 20356 20356 IN IP4 135.19.1.1
s=SDP data
c=IN IP4 135.19.1.1
t=0 0
m=audio 10447 RTP/AVP 107 101
a=rtpmap:107 opus/48000/2
a=fmtp:107 sprop-maxcapturerate=16000; maxaveragebitrate=20000; maxplaybackrate=48000;
useinbandfec=1
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=direction:active
a=nortpproxy:yes
a=oldmediaip:192.0.0.254
a=oldmediaip:192.168.0.84
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2277#issuecomment-614975630
1555
days inactive
1565
days old
14 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Sergiu Pojoga