asterisk users - Jul 2012 - chan_sip sending from wrong source address when multiple interfaces are used

> On 07/12/2012 09:19 AM, Benny Amorsen wrote:
>> "Kevin P. Fleming" <kpfleming at digium.com> writes:
>>
>>> That's quite interesting; can you describe a scenario where
this
>>> occurs?
>>
>> Imagine you have a server with two interfaces, eth0 with 192.168.1.1/24
>> and eth1 with 10.0.2.1/24. Further imagine that you wish to be able to
>> move phones between the networks without changing the SIP server
>> address, so you set 192.168.1.1 as the SIP server no matter which
>> network they happen to be on.
>>
>> Now the phones which happen to be connected to eth1 will send a request
>> to 192.168.1.1. If Asterisk is bound to 0.0.0.0, the reply will come
>> from 10.0.2.1. This could be solved if Asterisk did a connect() to the
>> socket and use the same socket for answering. That would tell the
system
>> IP stack that this is in fact a connection, and so the system would
>> ensure that the reply source IP would be correct.
>
> I must be missing something. If a phone sends a UDP packet to 
> 192.168.1.1, how does that get routed to (arrive at) the 10.0.2.1 
> interface on the Asterisk server? The only way I can imagine that 
> happening is if a router in between the phone and the server has been 
> told that 192.168.1.0/24 is reachable *through* 10.0.2.1, which seems 
> like a bizarre way to construct a network. Getting replies from 
> Asterisk *back* to the phone would also require the IP stack on the 
> Asterisk server to route those replies back over the 10.0.2.0/24 
> interface instead of the 192.168.1.0/24, which doesn't make any sense 
> either.
>
We have since Asterisk 1.2 been using a configuration with 6 NIC's 
bonding to 3 networks, one public internet and 2 private networks.
Routing calls between networks and having phones on all 3 networks is no 
problem.

There is one case though where we do fixup with iptables.
We have 30 virtuel adresses on one of the private networks and when 
Asterisk sends a packet to a destination then the first address of the 
NIC is inserted as source  by the OS.

example
one NIC has ip's
192.168.0.10,192.168.0.20,192.168.30
Telephone (192.168.0.100) sends a packet to Asterisk 192.168.0.30, 
Asterisk sends response to 192.168.0.100 but with source address 
192.168.0.10 as thats the first ip on that NIC.

In Iptables OUTPUT q we do a set-mark to an index into our source ip's
then in POSTROUTING we insert the source adr using the mark

b.r
Freddi




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20120712/f038d552/attachment.htm>

On 07/12/2012 12:38 PM, Freddi Hansen wrote:
> We have since Asterisk 1.2 been using a configuration with 6 NIC's
> bonding to 3 networks, one public internet and 2 private networks.
> Routing calls between networks and having phones on all 3 networks is no
> problem.
>
> There is one case though where we do fixup with iptables.
> We have 30 virtuel adresses on one of the private networks and when
> Asterisk sends a packet to a destination then the first address of the
> NIC is inserted as source  by the OS.
>
> example
> one NIC has ip's
> 192.168.0.10,192.168.0.20,192.168.30
> Telephone (192.168.0.100) sends a packet to Asterisk 192.168.0.30,
> Asterisk sends response to 192.168.0.100 but with source address
> 192.168.0.10 as thats the first ip on that NIC.
>
> In Iptables OUTPUT q we do a set-mark to an index into our source ip's
> then in POSTROUTING we insert the source adr using the mark
Yes, this is the situation I referred to earlier. In your case, it's all 
on one interface, but the server has multiple addresses on the *same* 
network, and thus it cannot know (without help) with address should be 
used for outbound packets.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org