| Summary: | ASTERISK-18203: Problems with NAT on realtime peers (and maybe static ones) | ||||
| Reporter: | daren ferreira (daren) | Labels: | |||
| Date Opened: | 2011-07-28 09:51:37 | Date Closed: | 2012-11-02 07:32:45 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General PBX/pbx_realtime | ||
| Versions: | 1.8.5.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | I just upgraded from 1.8.4.2 to 1.8.5.0 because of ASTERISK-17964 and related issues, to see if the leak was corrected, it was, but now i get NAT problems. My peers are set to nat=yes but asterisk send packets to their private IPs (fullcontact) instead of public IP (ipaddr). I didn't change anything else rtcachefriends from "yes" to "no" to test the leak i had on 1.8.4.2 | ||||
| Comments: | By: daren ferreira (daren) 2011-07-28 16:44:47.253-0500 After more tests i discovered that the problem was related to fullcontact information that pointed to a private ip, like "sip:s@192.168.0.240" and asterisk was using it... and so it failed (probably because not taking attention of NAT). After deleting fullcontact info from database the calls stopped to fail. I get a bit lost with asterisk way of managing NAT, for example i don't understand why it sends packets to private ip adress ( according to tcpdump ) and then use public IP address... In the previous issue, i don't understand why a buggy fullcontact made the call fails... Normally asterisk sends packets to private IP then if it fails and NAT is activated asterisk send packets to ipaddr:port got at registration time... but why a buggy fullcontact makes asterisk differ Then i don't know when fullcontact should be updated by asterisk. Since i emptied it to get calls to work, it has never been refilled by asterisk... even if peer registered dozens times since then... So because of all these questions i don't know if my issue is a real issue By: Walter Doekes (wdoekes) 2011-08-16 03:07:52.640-0500 I'm not a 100% sure, but I believe the following was the case when I looked into this on 1.6.2.x: (1) fullcontact is only written when rtcachefriends=yes (2) the (unaltered) Contact: header is stored there, so it could be a RFC1918 address (3) asterisk uses the ipaddr field from the DB if present for the IP-destination, and the fullcontact as the R-URI. i.e.: "INVITE <fullcontact> ..." sent to <ipaddr> I quick guess is that it still loads the fullcontact when rtcachefriends=no and uses that address for IP-destination => you're now sending to the RTF1918 addresses, if the fullcontact is still set. By: daren ferreira (daren) 2011-08-25 04:02:47.644-0500 Thank you for your comment, but according to my case, the way it should do is not the way it does. I discovered that even if rtcachefriends=no, fullcontact is used to reach the peer, packets are send to the RFC1918 ip address, and so it fails, and it never tries to use the ipaddr Since i reset the fullcontact fields of my peers, it first tries to send packets to private IP (maybe from asterisk internal database's /SIP/Registry information) and if it fails, it uses ipaddr (from realtime or asterisk internal database - no idea). Might it be considered as normal or as buggy? By: Rachickiy Andrey (gofman) 2011-09-02 12:44:19.100-0500 IP address changes to Private only after 'sip reload'. I confirm the problem with. voip*CLI> core show version Asterisk 1.8.6.0 A similar problem has already been - https://issues.asterisk.org/view.php?id=15194 But in version 1.8 already has a this patch I am really sorry for my bad English. By: Walter Doekes (wdoekes) 2011-09-09 01:32:13.129-0500 Are you guys listening on IPv6 as well? (bindaddr=[::] ?) By: Rachickiy Andrey (gofman) 2011-09-09 03:06:29.187-0500 I'm not listening to ipv6 [root@voip ~]# cat /etc/asterisk/sip.conf | grep -v '^;' | grep bindaddr | awk '{print $1}' udpbindaddr=109.198.XXX.XXX By: JoshE (n8ideas) 2012-10-16 22:25:31.066-0500 I can confirm this behavior also persists on Asterisk 10.9.0 as well. Register a realtime peer with a fullcontact that is behind NAT with rtcachefriends=yes and do a 'sip reload'. Make a call and Asterisk will query the database for the realtime peer. It will return the private address and so a 'sip show peers' shows the private IP address. If that peer is qualified, as many of them are, it will now go and stay unreachable until the peer re-registers, which resolves the issue. | ||||