Summary:	ASTERISK-03084: [patch] SIP failure on multihomed setup (intra&inter), -patch included-
Reporter:	benjamin9999 (benjamin9999)	Labels:
Date Opened:	2004-12-23 23:43:20.000-0600	Date Closed:	2005-04-01 00:26:51.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) byates-chan_sip-multihome.patch
Description:	maybe i've missed something but...  i have an asterisk box running on my home gateway/FW box which connects me to the public net (24.x.x.x) and also to my private subnet and corporate VPN (both 10.x.x.x).  i use sip friends which come from the private side (10.) and public internet.  when i try to establish a SIP connection, it incorrectly includes the machine's public IP as the SIP contact address, which is pulled from the bindaddr=0.0.0.0 default route info.  an externip can be configured, but that only helps for being a sip client behind a NAT.  i need to use my private IP when connecting with private (10.) clients, and public ip when connecting otherwise.  i don't see why this didn't exist before, but that's why i wonder if i just don't see the answer.  to fix the problem, i added a new sip.conf option internip= to match externip=.  when establishing SIP connections, if localnet= matches the address, then the new internip= address will be used if set, otherwise the older, bind=0000 ip will be used.  if the dest ip has no match in the localnet= table, then the externip is used.  it's real clean and works perfectly for me.  it seems like a -major- problem, it seems like this configuration of asterisk running on a GW/FW attached to multiple subnets should be quite common.  ...which is why i wonder if i just missed the obvious way to solve this problem without the option i added.  -benjamin ****** ADDITIONAL INFORMATION ******  this patch adds the option internip= to match externip=.  externip=24.1.2.3  internip=10.1.1.1  localnet=10.0.0.0/255.0.0.0  in this case, 24.1.2.3 will be used unless the SIP communication occurs within the localnet, then the internip 10.1.1.1 will be used.
Comments:	By: Olle Johansson (oej) 2004-12-24 02:44:04.000-0600 * What operating system are you using? * Is this patch disclaimed? Adding internip= seems to me to avoid fixing a routing problem. We are checking what address to use when sending packets, so packets should have the correct address on the internal network. There are two other bug reports in the bug tracker regarding this issue - did you check those? Also, the ast_ouraddrfor has been dramatically changed in cvs_head. Is it possible for you to try the same setup with asterisk cvs head and see if you have the same problem? By: Mark Spencer (markster) 2004-12-24 03:48:07.000-0600 Try this with latest CVS first and tell me if that changes the behavior... By: Olle Johansson (oej) 2004-12-30 02:32:28.000-0600 Please try with latest cvs head to see if it works for you. By: benjamin9999 (benjamin9999) 2004-12-30 10:21:06.000-0600 my os is linux 2.4.26. i use IPSec, with multiple subnets connected. the method to choose the IP to include in SIP messages is too simple in CVS-STABLE.  from my reading, there are only two choices....  1. destination is not localnet, gets externip.  2. destination is     localnet, gets -bindaddr-. my understanding is that if bindaddr is 0.0.0.0, then bindaddr's IP comes from the default route info for the machine. since asterisk is running ON the gateway, my bindaddr MUST remain 0.0.0.0, and the default route IS my public ip... therefore, when accessing another private subnet, the IP used is my public ip.  so SIP fails (one-way transmission). i tried HEAD on the 24th and got the same results, but i did not take the time to read over the code for what should have occured, i had also tried HEAD when i first discovered the SIP problem, and seemed to break my IAX with other STABLE boxes so i returned to STABLE. YES internip is a replacement for a better detection of IP based on the routing table, but i don't think it's too ugly myself, and quite easy to follow if you already have an understanding of the existing externip setting.  it might be a nice fix for STABLE and replace it with a better solution in HEAD.... edited on: 12-30-04 10:23 By: Mark Spencer (markster) 2005-01-09 03:40:55.000-0600 Latest CVS binds the socket, then gets the local address.  This should work for you provided that there is really only one route to where you're going. By: Mark Spencer (markster) 2005-01-12 23:50:57.000-0600 Are you still having a problem with CVS head? By: benjamin9999 (benjamin9999) 2005-01-19 10:03:43.000-0600 well i had a chance to try HEAD out at both sides, and the problem still exists. i gave it some more thought, and now i'm not sure where the burden lies.... the GW+asterisk box in question is also using IPsec (i did mention that in early notes), and i think the problem is in the ipsec0 device. openswan gives ipsec0 device the public ip (which seems to be proper), so any packets destined for that device (the internal SIP) will receive the public ip as its source.  most documentation i've used while setting up ipsec use SNAT to 'pin' outbound packets from the local machine to the private ip - i'm sure asterisk can't pick that up. so now i'm not sure.  2.6's ipsec stack is different, and does not use the ipsecN devices, so it probably doesn't have this issue.  i'm about to try it out..... By: Mark Spencer (markster) 2005-02-04 00:24:12.000-0600 Any luck?  Have you looked at bug ASTERISK-2326 to see if that would help you, too? By: Mark Spencer (markster) 2005-03-08 23:53:05.000-0600 This is a duplicate of 2358 and we have a working plan for it, so it's time to mark this as a dupe. By: Olle Johansson (oej) 2005-04-01 00:26:51.000-0600 ---duplicate bug report.