From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Fran=E7ois_Delawarde?= Date: Thu, 14 Dec 2006 11:44:57 +0000 Subject: Re: [LARTC] SIP, NAT, and load balancing problems Message-Id: <45813939.7010604@wirelessmundi.com> List-Id: References: <457EC047.7090404@wirelessmundi.com> In-Reply-To: <457EC047.7090404@wirelessmundi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org I unfortunately think that I can't use that solution (if I understood it=20 well). My box actually has two functions, it's an Asterisk box and a load=20 balancing router. For LAN clients, as this box represents their default gateway, there=20 would be no problem in implementing a pure routing solution. I could=20 create a new subnet on a dummy interface, and reconfigure all LAN SIP=20 phones to point to that IP, the box itself would route packets to its=20 dummy interface. For WAN clients, what I need is to have a unique interface (a unique=20 public IP) accepting SIP connections, and outgoing traffic always=20 passing by this interface. My current issue is with outgoing SIP/RTP=20 traffic that sometimes gets load-balanced and uses the other public IP,=20 which i have to force to the other interface, with lots of=20 NATing/Re-Routing problems, as a single call can have multiple UDP flows=20 (SIP and RTPs). My main problem with the DummyNet solution on the WAN side is that I=20 cannot access to the internet routers behind this box, so I can't add=20 routes to reach a new subnet. This means that I'm back with the same=20 type of problem trying to NAT, but this time not only the box's outgoing=20 traffic, but also the clients incoming traffic, for them to reach the=20 dummy0 interface. Tell me if i'm wrong, but that solutions appears to me as more=20 complicated in my particular case. Aouch, that's much harder than I=20 thought it would be. :-( Fran=E7ois. Grant Taylor wrote: > Fran=E7ois Delawarde wrote: >> What i meant is that people (in #asterisk on freenode) told me that=20 >> Asterisk could be bound to a unique IP, or to all IPs (binding it to=20 >> 0.0.0.0). But if you know a way to bind it to only some IPs, then=20 >> yeah! I need your help :-) I guess we need to put something in the=20 >> bindaddr parameter of sip.conf. Right now I have: >> >> [general] >> bindaddr=3D0.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=20 >> 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=20 >>> to your other network, you could end up with some really weird=20 >>> issues that will be very difficult to over come, probably MUCH=20 >>> harder than resolving the issue with Asterisk only binding to one=20 >>> interface. >> >> I don't really understand what you mean, but that's right, i have=20 >> 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=20 > IP, and 192.2.0.254/24 is assigned to the dummy0 interface. If you=20 > bind Asterisk to the 192.2.0.254 IP on the dummy0 interface, you will=20 > have to route all traffic that is to or from Asterisk in to and out of=20 > the dummy0 network. > > Now that you can easily see that you would have to route traffic in to=20 > and out of the dummy0 interface, I can probably better explain the=20 > weird routing issue that you have. You are binding Asterisk to an IP=20 > on your system. No matter what IP you bind Asterisk to, traffic from=20 > 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=20 > interface, traffic to / from your LAN or the other WAN interface will=20 > have to be routed to be able to reach Asterisk. If you bind Asterisk=20 > to the LAN interface, traffic to / from either WAN will have to be=20 > routed to be able to reach Asterisk. > > Usually routing traffic is not an issue. However, as you have pointed=20 > out, when you MASQUERADE traffic as it leaves either of your WAN=20 > interfaces, the port numbers are changed and thus breaking your SIP=20 > connection. > > So, you need to be able to not alter the SIP packet stream. So, what=20 > you need to really do is only alter traffic that is not originating /=20 > terminating on your firewall. You could do this a few different ways.=20 > Probably the easiest way would be to not MASQUERADE any traffic, save=20 > for traffic that originates on your LAN, not the firewall / Asterisk=20 > box it's self. > > You will probably also need to do something to make sure that your SIP=20 > traffic is not subject to load balancing. If you set up some sort of=20 > identifier for your SIP traffic, say locally originated / terminated,=20 > you could use a custom routing table to not load balance the traffic=20 > via multiple next hops. > > One advantage of having Asterisk bind to a completely different IP,=20 > i.e. on the dummy0 interface is that you could set up a rule that=20 > looked for source or target IPs in the subnet on dummy0 as a VERY easy=20 > 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=20 >> two IPs (2 WAN with load balancing)? And do you know at what moment=20 >> this IP is chosen? Do you think I can trick the routing subsystem (or=20 >> whoever decides the IP) to force the decision? > > Sorry, I don't know what moment the decision is made. Nor do I think=20 > you could ""Trick the routing sub system once it has made a decision.=20 > Sure, you can do some things to over ride which interface is used to=20 > carry out the decision that was made. I think what would be better=20 > would be to influence / control the possibilities that the routing sub=20 > system has to choose from. > >> I'll try to check on that, if i can't resolve the issue with Asterisk=20 >> bindings. > > *nod* > > > > Grant. . . . > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc