Support for 192.0.0.0/24 as NATed source (follow-up) #2277

girevikman · 2020-04-07T15:48:38Z

Description

Follow-up to previous closed PR #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

(paste your debugging data here)

Log Messages

(paste your log messages here)

SIP Traffic

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

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:

Debian 8
Linux proxy1 2.6.32-39-pve #1 SMP Fri May 8 11:27:35 CEST 2015 x86_64 GNU/Linux

The text was updated successfully, but these errors were encountered:

henningw · 2020-04-07T16:49:35Z

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 */

girevikman · 2020-04-07T17:07:43Z

@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-special-registry.xhtml

henningw · 2020-04-07T19:05:46Z

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                           |
        +----------------------+---------------------------------+

miconda · 2020-04-07T20:50:52Z

@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.

henningw · 2020-04-08T06:09:14Z

@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.

miconda · 2020-04-08T06:39:41Z

Edited the title to reflect it is about /24 and added feature request by reopening it.

- if set to 0, default private net addresses are checked by nat_uac_test() - if set to 1, other reserved net addresses are checked by nat_uac_test() - default 1 (reserved addresses are considered not routable) - related at GH #2277

miconda · 2020-04-16T10:02:19Z

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.

henningw · 2020-04-16T10:16:53Z

Thanks Daniel - fine with me to have it activated by default. But good to have it configurable if in the future it changes again.

miconda · 2020-04-16T14:57:03Z

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.

girevikman · 2020-04-17T01:01:19Z

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

- if set to 0, default private net addresses are checked by nat_uac_test() - if set to 1, other reserved net addresses are checked by nat_uac_test() - default 1 (reserved addresses are considered not routable) - related at GH #2277 (cherry picked from commit a10e765)

henningw closed this as completed Apr 7, 2020

miconda changed the title ~~Support for 192.0.0.0/29 as NATed source (follow-up)~~ Support for 192.0.0.0/24 as NATed source (follow-up) Apr 8, 2020

miconda added the feature-request label Apr 8, 2020

miconda reopened this Apr 8, 2020

miconda closed this as completed Apr 16, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for 192.0.0.0/24 as NATed source (follow-up) #2277

Support for 192.0.0.0/24 as NATed source (follow-up) #2277

girevikman commented Apr 7, 2020

henningw commented Apr 7, 2020

girevikman commented Apr 7, 2020 •

edited

henningw commented Apr 7, 2020

miconda commented Apr 7, 2020

henningw commented Apr 8, 2020

miconda commented Apr 8, 2020

miconda commented Apr 16, 2020

henningw commented Apr 16, 2020

miconda commented Apr 16, 2020

girevikman commented Apr 17, 2020 •

edited

Support for 192.0.0.0/24 as NATed source (follow-up) #2277

Support for 192.0.0.0/24 as NATed source (follow-up) #2277

Comments

girevikman commented Apr 7, 2020

Description

Troubleshooting

Reproduction

Debugging Data

Log Messages

SIP Traffic

Possible Solutions

Additional Information

henningw commented Apr 7, 2020

girevikman commented Apr 7, 2020 • edited

henningw commented Apr 7, 2020

miconda commented Apr 7, 2020

henningw commented Apr 8, 2020

miconda commented Apr 8, 2020

miconda commented Apr 16, 2020

henningw commented Apr 16, 2020

miconda commented Apr 16, 2020

girevikman commented Apr 17, 2020 • edited

girevikman commented Apr 7, 2020 •

edited

girevikman commented Apr 17, 2020 •

edited