Summary:ASTERISK-16728: Incorrect registrations and/or Check Authorization of NAT SIP devices
Reporter:Jose (jlaguilar)Labels:
Date Opened:2010-09-24 12:51:46Date Closed:2011-06-07 14:05:20
Versions:Frequency of
Description:When realtime SIP devices behind NAT register, the following fields get populated by asterisk in the database: fullcontact, ipaddr, port.

We are currently experiencing that the fullcontact field gets populated with the internal port used by the device in the LAN and the port fields gets populated by the actual port used to contact asterisk in the public internet. For example:

| name | fullcontact                  | ipaddr         | port  |
| 1003 | sip:1003@74.211.XXX.XXX:1066 | 74.211.XXX.XXX |  1073 |
| 1004 | sip:1004@74.211.XXX.XXX:1073 | 74.211.XXX.XXX |  1077 |

SIP device 1003 is using UDP port 1066 in the local network, but the router is mapping that port to the external UDP port 1073 (public network), which is the port asterisk is getting the network connection from (This is the correct behavior for NAT devices). Likewise SIP device 1004 is using UDP port 1073 in the LAN, and the router maps to port 1077 in the public network.

In this scenario, both devices are able to receive inbound calls, but SIP device 1004 is not able to dial out. It gets the following error: username mismatch, have <1003>, digest has <1004>. SIP configuration (insecure=no).

Inbound calls work because asterisk is routing correctly to the IP address and port it got from the network connections (NAT devices). In this case it sends the call to IP 74.211.XXX.XXX and port 1073 for device 1003 and port 1077 for device 1004. The router maps to the internal ports and the calls work.

For outbound calls, asterisk is trying to check peer authorization based on the SIP header information which advertises the internal port (In our example sip:1004@74.211.XXX.XXX:1073) instead of using the port of the received network connection, and then tries to match the peer in its table to the peer registered in IP address 74.211.XXX.XXX and port 1073. As you can see, the peer registered in the external port 1073 is SIP device 1003 (Not 1004), and the call fails with the error: username mismatch, have <1003>, digest has <1004>.

This only happens when an internal port number being used by one device matches an external port being used by another device from the same IP address (NAT). It doesn't happen a lot, but it does happen. If there are no matches, the SIP device is authenticated correctly.

Comments:By: Walter Doekes (wdoekes) 2010-09-24 14:06:25

(1) Did asterisk rewrite a LAN ip in the fullcontact, or did your NATed devices already send the external IP? If your phone sends a Contact with an external IP (and is lying), then it is not odd that asterisk could get confused. (If your phone sends a LAN ip, then asterisk would be at fault though.)

(2) Does setting match_auth_username=yes in [general] fix it for you?

By: Stefan Tichy (st) 2010-09-27 08:09:17

WARNING[16991] chan_sip.c: username mismatch, have <12>, digest has <13>

Got the same message using Asterisk, realtime SIP config, devices
behind NAT (same IP), but TLS connections are used.

First phone does work
Second phone cannot make outgoing calls and Asterisk logs that message
Third phone does work

If first phone unregisters the second one will work until the first registers again. Two Snom 3x0 phones and one Nokia have been used, but this seems to be insignificant. Until now I did not find anything usefull in the log files.

By: Leif Madsen (lmadsen) 2010-09-28 10:55:15

This sounds like you should be using:  insecure=port

I think this is the exact scenario that option was designed for. Give it a shot and report back.

By: Stefan Tichy (st) 2010-09-28 11:33:25

sip.conf.sample: insecure=port

"Allow matching of peer by IP address without matching port number"

This is useful if Asterisk is located behind some NAT device and registers to a provider. But is it a good idea to ignore port information while Asterisk has to deal with several phones behind the same NAT device?

By: Stefan Schmidt (schmidts) 2010-09-28 13:33:06

sound like the simple but stupid SIP ALG which most of the routers use (even cisco has this active by default). i dont know which router you use, but turn this off so your router just sends out the right contact header (internal) without changing parts of the header it shouldnt, and this will work.

By: Stefan Tichy (st) 2010-10-01 08:59:16

In this case I probably should open another issue concerning the TCP/TLS realtime DB problem. Fullcontact is not modified in this test scenario.

By: Jose (jlaguilar) 2010-10-01 09:27:48

Disabling the SIP ALG in the router fixed my issue. Anyway, I think asterisk should be smart enough to not use and not care about the fullcontact information if the device is configured as a NAT device.

By: Stefan Schmidt (schmidts) 2010-10-01 13:01:11

asterisk can only work with the information which are received and a malformed sip package (SIP ALG is allways wrong) would be handled as it is received.

if your router does it right even with sip alg you wont have a contact and source port missmatch so this would not happend but atleast i have not seen a single router which does this right. for example cisco, zyxel, pirelli, oneaccess, linksys, netgear, fritzbox.