[Home]

Summary:ASTERISK-06867: [patch] externip replacement is made regardless of 'true' source IP
Reporter:Luke-Jr (luke-jr)Labels:
Date Opened:2006-04-28 09:18:25Date Closed:2007-06-30 09:20:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) externip-nat-check-0.1.patch
Description:externip is describes as a "Address that we're going to put in outbound SIP messages if we're behind a NAT", but does not check for "if we're behind a NAT". While it verifies that the *destination* *is* behind a NAT as well, it does not verify that Asterisk itself is behind the NAT. Thus, if Asterisk is sending a SIP message from "24.30.55.3" and externip=65.2.2.2, then Asterisk will place "65.2.2.2" in the message even though it is not behind a NAT and should put "24.30.55.3"

****** ADDITIONAL INFORMATION ******

Patch attached. Thus far, it is 100% untested. Distributed under the BSD license, which means you don't need a specific disclaimer for Digium (or anyone else).
Comments:By: Olle Johansson (oej) 2006-05-02 15:23:07

Are you using the localnet= setting at all? That's what we use to verify whether the IP is outside of our local network.
By: Luke-Jr (luke-jr) 2006-05-02 15:28:16

Yes. While Asterisk correctly checks to be sure the *destination* IP is *outside* the localnet, it does not check to be sure the *source* IP would otherwise be *inside* the localnet. Thus, even if Asterisk is sending from a public IP, the value of externip will still replace the true IP in SIP packets, which it should not.
By: Olle Johansson (oej) 2006-05-11 02:13:33

Do you have several IPs on your server?

Can you attach a SIP debug with verbose/debug 4 so we can see when this happens?
By: Luke-Jr (luke-jr) 2006-05-11 14:53:37

Normal situation: lan0 has IP 192.168.77.76 (behind a NAT as backup/secondary route); inet0 (default/primary route) has a public 24.x.x.x IP. In these circumstances, no NAT is involved. If "externip" is set, however, Asterisk sends packets with the externip value in the headers (which it should not, since it is not behind a NAT in this case). This causes "normal circumstances" traffic to route through the NAT when it shouldn't, which is a problem also because lan0 has less bandwidth.

Potential situation: inet0 is offline/down. Internet traffic falls back to NAT via lan0/192.168.77.76. Now, Asterisk should make the externip replacement, as the packets would otherwise be originating from a LAN IP address and Asterisk is thus now behind a NAT. If "externip" is set, this situation works fine.
By: Serge Vecher (serge-v) 2006-05-22 13:49:25

Luke-Jr: we still need the SIP debig as requested by OEJ. Thanks
By: Luke-Jr (luke-jr) 2006-05-24 02:11:48

Why is that? The patch clearly shows both the problem and the fix, and nothing similar even appears in the current Asterisk source. Basically, there is no code even *attempting* to make externip work as documented. It relies on the assumption that someone without a NAT will not specify it, which is only a real problem when in a situation where both NAT and non-NAT connections are possible.
By: Joshua C. Colp (jcolp) 2006-05-26 12:50:42

Thanks for your contribution but based on discussion with oej we both agree that the person who set up the system shouldn't set localnet if they are not behind NAT, so we are not going to be including this patch at this time. In the future once our STUN situation is settled, this should no longer be an issue. Thanks anyway!
By: Luke-Jr (luke-jr) 2006-05-26 15:55:23

The problem is that localnet is *ignored* with the source address, and externip is applied regardless of NAT situation. This bug affects my real-world Asterisk box by breaking either normal operation (a direct internet connection) or backup operation (via NAT).
This fix changes externip to behave *as already documented* (thus, it being a bugfix isn't really disputable) and should have no negative effects.

Minor point: the category "NAT traversal" isn't quite accurate since the bug occurs in the non-NAT situation.
By: Joshua C. Colp (jcolp) 2006-05-26 16:26:24

If you really insist on getting this in I would feel much more comfortable having it as a configurable option, and as well we would need a disclaimer on file.
By: Luke-Jr (luke-jr) 2006-05-26 23:06:34

This shouldn't change any expected behavior-- it just makes * do what the documentation says it already does. Is there a use case for having a configurable option (eg, any circumstance where this fix would have a negative effect)?
By: Joshua C. Colp (jcolp) 2006-05-30 11:02:19

I've thought about this during the weekend and I've come to this:

I will accept this into trunk, and put add a note dictating this behavior so that if we do find a situation where it doesn't work as expected - we can defend ourselves or in the end reverse it. How's that?
By: Luke-Jr (luke-jr) 2006-05-30 20:35:42

Sure, but do note that this behavior is already documented as "if we're behind a NAT"
By: Joshua C. Colp (jcolp) 2006-05-31 11:31:55

Put into trunk as of revision 31050.