All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SIP, NAT, and load balancing problems
Date: Wed, 13 Dec 2006 20:48:33 +0000	[thread overview]
Message-ID: <45806721.7020504@riverviewtech.net> (raw)
In-Reply-To: <457EC047.7090404@wirelessmundi.com>

François Delawarde wrote:
> What i meant is that people (in #asterisk on freenode) told me that 
> Asterisk could be bound to a unique IP, or to all IPs (binding it to 
> 0.0.0.0). But if you know a way to bind it to only some IPs, then yeah! 
> I need your help :-) I guess we need to put something in the bindaddr 
> parameter of sip.conf. Right now I have:
> 
> [general]
> bindaddr=0.0.0.0
> 
> I have 3 IPs in 3 interfaces:
> eth0 (LAN): 192.168.10.1
> eth1 (WAN): 192.168.1.2 (gw 192.168.1.1)
> eth2 (WAN): 192.168.2.2 (gw 192.168.2.1)
> 
> How can I bind Asterisk SIP to 192.168.10.1 and 192.168.2.2 only, to 
> work around my load balancing problem?

I'll email you off the mailing list as this does not pertain to LARTC.

>> If Asterisk is only listening to one IP and you are routing to get to 
>> your other network, you could end up with some really weird issues 
>> that will be very difficult to over come, probably MUCH harder than 
>> resolving the issue with Asterisk only binding to one interface.
> 
> I don't really understand what you mean, but that's right, i have really 
> weird issues.

What I was saying is that if Asterisk is only bound to one IP address,
be it loopback, eth0, eth1, or even a dummy0 interface, you will have to
route traffic to that address.

If you can indeed only bind Asterisk to only one IP address or all IP
addresses on the system, I would recommend that you use DummyNet to bind
Asterisk to.  However this may be a problem down when NATing comes in to
play.  (More on this later.)

Supposing that you bind Asterisk to the dummy0 interface, either all
equipment will need to its self know how, or the default router for the
equipment will need to know how to reach the subnet on the dummy0
interface.  This usually means that you will have to have the default
gateway for all client systems / phones know how to reach the subnet on
the dummy0 interface.  I.e. the default gateway will have to have a
route to the subnet on the dummy0 interface via the interface on the
Asterisk box facing the router(s).

Consider:
                    +----------------------+
                    |     Asterisk Box     |
                    |         [A.B.C.D/NM]-|---(INet)
(192.168.0.0/24)---|-[192.168.0.254/24]   |
                    |   [192.2.0.254/24]   |
                    |          |           |
                    +----------------------+
                               |
                            [dummy0]

In this case, 192.168.0.254/24 is the LAN, the internet is it's own IP, 
and 192.2.0.254/24 is assigned to the dummy0 interface.  If you bind 
Asterisk to the 192.2.0.254 IP on the dummy0 interface, you will have to 
route all traffic that is to or from Asterisk in to and out of the 
dummy0 network.

Now that you can easily see that you would have to route traffic in to 
and out of the dummy0 interface, I can probably better explain the weird 
routing issue that you have.  You are binding Asterisk to an IP on your 
system.  No matter what IP you bind Asterisk to, traffic from any other 
subnet will have to be routed to that subnet to reach Asterisk.

With this in mind, now consider if you bind Asterisk to one WAN 
interface, traffic to / from your LAN or the other WAN interface will 
have to be routed to be able to reach Asterisk.  If you bind Asterisk to 
the LAN interface, traffic to / from either WAN will have to be routed 
to be able to reach Asterisk.

Usually routing traffic is not an issue.  However, as you have pointed 
out, when you MASQUERADE traffic as it leaves either of your WAN 
interfaces, the port numbers are changed and thus breaking your SIP 
connection.

So, you need to be able to not alter the SIP packet stream.  So, what 
you need to really do is only alter traffic that is not originating / 
terminating on your firewall.  You could do this a few different ways. 
Probably the easiest way would be to not MASQUERADE any traffic, save 
for traffic that originates on your LAN, not the firewall / Asterisk box 
it's self.

You will probably also need to do something to make sure that your SIP 
traffic is not subject to load balancing.  If you set up some sort of 
identifier for your SIP traffic, say locally originated / terminated, 
you could use a custom routing table to not load balance the traffic via 
multiple next hops.

One advantage of having Asterisk bind to a completely different IP, i.e. 
on the dummy0 interface is that you could set up a rule that looked for 
source or target IPs in the subnet on dummy0 as a VERY easy and clear 
identifier as the traffic would belong to Asterisk.

> What happens in my case, where default subnet (0.0.0.0/0 subnet) has two 
> IPs (2 WAN with load balancing)? And do you know at what moment this IP 
> is chosen? Do you think I can trick the routing subsystem (or whoever 
> decides the IP) to force the decision?

Sorry, I don't know what moment the decision is made.  Nor do I think 
you could ""Trick the routing sub system once it has made a decision. 
Sure, you can do some things to over ride which interface is used to 
carry out the decision that was made.  I think what would be better 
would be to influence / control the possibilities that the routing sub 
system has to choose from.

> I'll try to check on that, if i can't resolve the issue with Asterisk 
> bindings.

*nod*



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2006-12-13 20:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-12 14:44 [LARTC] SIP, NAT, and load balancing problems François Delawarde
2006-12-12 19:54 ` Andrew McGill
2006-12-13  6:40 ` Grant Taylor
2006-12-13 10:12 ` François Delawarde
2006-12-13 10:33 ` François Delawarde
2006-12-13 15:30 ` Taylor, Grant
2006-12-13 20:48 ` Grant Taylor [this message]
2006-12-13 21:57 ` Grant Taylor
2006-12-13 22:44 ` Grant Taylor
2006-12-13 22:57 ` Patrick McHardy
2006-12-14 11:44 ` François Delawarde
2006-12-14 11:59 ` François Delawarde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45806721.7020504@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.