[asterisk-bugs] [JIRA] (ASTERISK-20904) RFC1918 NAT Issue On Prune

[Michael L. Young (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201347#comment-201347 ] 

Michael L. Young edited comment on ASTERISK-20904 at 1/10/13 10:49 PM:
-----------------------------------------------------------------------

Give this patch a try, if you could.  [^asterisk-20904-auto-nat-prune_v1.diff]

A few things.  The default global nat setting is now auto_force_rport.  Keep that in mind. I have updated the CHANGES file to state that.  Even though nat=yes was deprecated, I think it was the changes to add auto_force_rport and auto_comedia and then setting auto_force_rport as the default global setting which caused this bug to appear in branch 11.

The force_rport setting was having no effect because the flags used to turn those bits on and off were not being applied until later in the code, instead of before we needed them.  I have moved that code up before we start needing to use those flags.

The check for "found" in relation to realtime is when we have realtime caching on.  So, I changed it to not check for realtime but rather whether we have realtime caching on or not.  This seems to take care of the reload problem from the other issue.

The prune problem is fixed by adding a check to see if nat was detected or not from the request coming from the peer when auto_force_rport is on.  When it is not on, it is also fixed by moving those flags for determining if force_rport is on or not to being called sooner as I explained up above.

Let me know if that solves your problem.  It seemed to be working well in my testing.  I had to do a lot of debugging before finally pinpointing the exact areas where the problems were.
                
      was (Author: elguero):
    Give this patch a try, if you could.

A few things.  The default global nat setting is now auto_force_rport.  Keep that in mind. I have updated the CHANGES file to state that.  Even though nat=yes was deprecated, I think it was the changes to add auto_force_rport and auto_comedia and then setting auto_force_rport as the default global setting which caused this bug to appear in branch 11.

The force_rport setting was having no effect because the flags used to turn those bits on and off were not being applied until later in the code, instead of before we needed them.  I have moved that code up before we start needing to use those flags.

The check for "found" in relation to realtime is when we have realtime caching on.  So, I changed it to not check for realtime but rather whether we have realtime caching on or not.  This seems to take care of the reload problem from the other issue.

The prune problem is fixed by adding a check to see if nat was detected or not from the request coming from the peer when auto_force_rport is on.  When it is not on, it is also fixed by moving those flags for determining if force_rport is on or not to being called sooner as I explained up above.

Let me know if that solves your problem.  It seemed to be working well in my testing.  I had to do a lot of debugging before finally pinpointing the exact areas where the problems were.
                  
> RFC1918 NAT Issue On Prune
> --------------------------
>
>                 Key: ASTERISK-20904
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20904
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>            Reporter: JoshE
>            Assignee: Michael L. Young
>         Attachments: asterisk-20904-auto-nat-prune_v1.diff, rfc1918_patch.diff
>
>
> Issue is related to ASTERISK-20572, but appears to have been reintroduced in Asterisk 11.x.
> Bring up a realtime peer behind separated from the Asterisk server behind NAT.   When the peer is pruned and brought back up, the peer's external NAT address is replaced with the private IP from the contact header, if that address was present.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira