> This seems very counter-intuitive for anyone that has their asterisk > server on a public IP address and serves clients both behind and not > behind NAT. I've always viewed it as the nat= setting inside the > [general] context is for whether or not the asterisk server itself is > behind a NAT, and then the nat= setting inside each [peer] definition > is based on whether or not that particular peer / endpoint was behind > nat or not. Have I viewed it incorrectly all this time?
Yes, you have viewed it incorrectly all this time. :-) [general] sets the default, and [peer] settings override it. > On that note, why have the nat= setting on peers in the first place if > it's insecure / not recommended to have a setting that differs from > the general nat= setting. I'm not trying to be smug, I'm generally > curious about the reasoning behind taking this approach to deal with > this security issue, instead of changing code somewhere (I'm not a > programming, and thus have no idea how complicated such a change would > be). Because we try not to make policy decisions for the users. If someone has two devices, one behind a nat, and one not *and* the nat=yes setting does not work for the phone that isn't behind the nat (I believe some Cisco phones may have some issues with nat=yes), we aren't going to tell the user they can't use Asterisk. We will warn them that what they are doing is a *potential* security risk so that they can take other precautions to avoid any issue. Most phones support TCP and TCP doesn't have this issue. So really, it would be awesome if people would just use that. As to why their wasn't a code fix, basically there isn't (a palatable) one. nat=yes and nat=no cause differing behavior. It is their entire reason for existing. We can fake responses to unknown users so that we respond the same way to known and unknown users, but the only way to fake reliably when there are both nat=yes and nat=no users is to send the responses to *both* the port a request came from and the port listed in the Via header. We could do this, but it is a really ugly non-standard kind of thing to do and certainly not something we would do in a release branch. For more discussion on this issue (as we discussed it with the community to see what everyone thought we should do) see: http://lists.digium.com/pipermail/asterisk-dev/2011-November/052191.html Terry Terry -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
