<!-- 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@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@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@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 ```
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 */
@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-specia...
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 | +----------------------+---------------------------------+
Closed #2277.
@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.
@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.
Edited the title to reflect it is about `/24` and added feature request by reopening it.
Reopened #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.
Closed #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.
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.
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
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@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@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 ```
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Sergiu Pojoga