LARTC - Dec 2006 - SIP, NAT, and load balancing problems

Hello all,

I have a linux machine with a SIP server (Asterisk) and 2 WAN interfaces 
(NATed) configured to do load balancing. I experienced problems with the 
SIP/RTP protocols and load balancing, because when initiating a call to 
an external SIP Host, a new RTP flow starts from the server to the Host, 
that sometimes uses another default route (due to the nexthop 
configuration). As i have two different public IPs, the external host 
gets confused while receiving flows from different IPs, and doesn''t
work
(or sometimes we only have one-way communication).

            __________
           |          |-eth1---|Router ISP 1|---WAN 1
LAN---eth0-|SIP Server|
           |__________|-eth2---|Router ISP 2|---WAN 2


What I basicly want is to force all traffic from my SIP server to pass 
by a unique WAN interface (eth2), or to find a solution that would force 
multiple sessions from the same IP to use the same WAN interface. 
Reading various forums and mailing lists, I decided to try to do "output 
re-routing" to all traffic sent to the wrong interface:

(5060 is SIP port and 10000-20000 are the possible RTP ports)

1. using FWMARK and iproute2:

iptables -t mangle -A OUTPUT -o eth1 -p udp --sport 5060 -j MARK 
--set-mark 0x101
iptables -t mangle -A OUTPUT -o eth1 -p udp --sport 10000:20000 -j MARK 
--set-mark 0x101
ip rule add prio 101 fwmark 0x101 table 101
ip route add default via 192.168.2.1 dev eth2 src 192.168.2.2 table 101
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

The redirection is working, but the source port is changed by the 
MASQUERADE, and this doesn''t work with SIP/RTP, which contain reply 
information (ip/port) inside its packets.


2. iptables ROUTE target:

iptables -t mangle -A OUTPUT -o eth1 -p udp --dport 5060 -j ROUTE --oif 
eth2 --gw 192.168.2.1 --continue
iptables -t mangle -A OUTPUT -o eth1 -p udp --dport 10000:20000 -j ROUTE 
--oif eth2 --gw 192.168.2.1 --continue
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

Even with SNAT or MASQUERADE rules, the source IP of the packet is not 
changed when using these ROUTE targets, the router connected to eth2 
then drops the packets.


Below you can find my network configuration (rules, routes and 
addresses). Anyone has an idea of how i could resolve this problem?

Thanks,
François.

On Tuesday Dec 12, 2006 around 3:44pm, François Delawarde wrote,
> Hello all,
>
> I have a linux machine with a SIP server (Asterisk) and 2 WAN interfaces 
> (NATed) configured to do load balancing. I experienced problems with the 
> SIP/RTP protocols and load balancing, because when initiating a call to an 
> external SIP Host, a new RTP flow starts from the server to the Host, that 
> sometimes uses another default route (due to the nexthop configuration). As
i
> have two different public IPs, the external host gets confused while 
> receiving flows from different IPs, and doesn''t work (or sometimes
we only
> have one-way communication).
There is a similar problem with openvpn which the --multihome 
patch in 2.1_rc* solves (SOL_IP / IP_PKTINFO option on the 
socket).  Unless the application (asterisk in your case) chooses 
to bind a UDP socket to a particular IP address, the routing 
subsystem will assign the IP address.  Since UDP is 
connectionless, there is no reason to use the same IP address as 
the incoming ''connection''.  (ip_conntrack doesn''t
count.)

*You* may be able to solve the problem with some creative use of 
the CONNMARK target (I didn''t succeed). The best solution, in the 
absence of a kernel hack to treat UDP as a connection-oriented 
protocol, is to fix asterisk (IMHO, IANAKH).

&:-)


>
>           __________
>          |          |-eth1---|Router ISP 1|---WAN 1
> LAN---eth0-|SIP Server|
>          |__________|-eth2---|Router ISP 2|---WAN 2
>
>
> What I basicly want is to force all traffic from my SIP server to pass by a
> unique WAN interface (eth2), or to find a solution that would force
multiple
> sessions from the same IP to use the same WAN interface. Reading various 
> forums and mailing lists, I decided to try to do "output
re-routing" to all
> traffic sent to the wrong interface:
>
> (5060 is SIP port and 10000-20000 are the possible RTP ports)
>
> 1. using FWMARK and iproute2:
>
> iptables -t mangle -A OUTPUT -o eth1 -p udp --sport 5060 -j MARK --set-mark
> 0x101
> iptables -t mangle -A OUTPUT -o eth1 -p udp --sport 10000:20000 -j MARK 
> --set-mark 0x101
> ip rule add prio 101 fwmark 0x101 table 101
> ip route add default via 192.168.2.1 dev eth2 src 192.168.2.2 table 101
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
> iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
>
> The redirection is working, but the source port is changed by the
MASQUERADE,
> and this doesn''t work with SIP/RTP, which contain reply
information (ip/port)
> inside its packets.
>
>
> 2. iptables ROUTE target:
>
> iptables -t mangle -A OUTPUT -o eth1 -p udp --dport 5060 -j ROUTE --oif
eth2
> --gw 192.168.2.1 --continue
> iptables -t mangle -A OUTPUT -o eth1 -p udp --dport 10000:20000 -j ROUTE 
> --oif eth2 --gw 192.168.2.1 --continue
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
> iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
>
> Even with SNAT or MASQUERADE rules, the source IP of the packet is not 
> changed when using these ROUTE targets, the router connected to eth2 then 
> drops the packets.
>
>
> Below you can find my network configuration (rules, routes and addresses). 
> Anyone has an idea of how i could resolve this problem?
>
> Thanks,
> François.
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
-- 
Disclaimer: our lawyers will sue us if you copy this disclaimer

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

On 12/12/06 08:44, François Delawarde wrote:
> I have a linux machine with a SIP server (Asterisk) and 2 WAN interfaces 
> (NATed) configured to do load balancing. I experienced problems with the 
> SIP/RTP protocols and load balancing, because when initiating a call to 
> an external SIP Host, a new RTP flow starts from the server to the Host, 
> that sometimes uses another default route (due to the nexthop 
> configuration). As i have two different public IPs, the external host 
> gets confused while receiving flows from different IPs, and
doesn''t work
> (or sometimes we only have one-way communication).
IMHO this is what I would expect SIP VoIP traffic to do in this scenario.
> What I basicly want is to force all traffic from my SIP server to pass 
> by a unique WAN interface (eth2), or to find a solution that would force 
> multiple sessions from the same IP to use the same WAN interface. 
> Reading various forums and mailing lists, I decided to try to do
"output
> re-routing" to all traffic sent to the wrong interface:
> 
> (5060 is SIP port and 10000-20000 are the possible RTP ports)
<snip>
> The redirection is working, but the source port is changed by the 
> MASQUERADE, and this doesn''t work with SIP/RTP, which contain
reply
> information (ip/port) inside its packets.
If Asterisk is running directly on the firewall box, why are you even 
MASQUERADEing or SNATing the packets?  Why not have Asterisk bind 
directly to the external IP?  This way MASQUERADE will not get in your 
way as far as changing the ports on you.
> Even with SNAT or MASQUERADE rules, the source IP of the packet is not 
> changed when using these ROUTE targets, the router connected to eth2 
> then drops the packets.
Sorry, I have not worked with the ROUTE target so I can not help.
> Below you can find my network configuration (rules, routes and 
> addresses). Anyone has an idea of how i could resolve this problem?
I''m looking, but for some reason I can not find it.  ;)

Some things to consider:
  - Set up a routing table just for Asterisk.
  - Identify Asterisk traffic via MARKed packets.
  - MARK the packets based on the OWNER match extension.  To do this 
Asterisk would need to run as it''s own user, which should not be a
problem.



Grant. . . .

Thank you for suggestions, below are my comments:

Grant Taylor wrote:
>> The redirection is working, but the source port is changed by the 
>> MASQUERADE, and this doesn''t work with SIP/RTP, which contain
reply
>> information (ip/port) inside its packets.
>
> If Asterisk is running directly on the firewall box, why are you even 
> MASQUERADEing or SNATing the packets?  Why not have Asterisk bind 
> directly to the external IP?  This way MASQUERADE will not get in your 
> way as far as changing the ports on you.
It''s actually the first thing i tried, but as I need to offer service
to
both WAN and LAN, and the Asterisk SIP cannot bind to multiple IPs. It 
only offers to bind it to a unique IP or 0.0.0.0 (and from the feedback 
i got, they don''t intend to implement that any time soon). I could 
probably run multiple instances or implement this myself, but I don''t 
have that much talent and time to do those complicated things. :-)
>> Below you can find my network configuration (rules, routes and 
>> addresses). Anyone has an idea of how i could resolve this problem?
>
> I''m looking, but for some reason I can not find it.  ;)
>
> Some things to consider:
>  - Set up a routing table just for Asterisk.
>  - Identify Asterisk traffic via MARKed packets.
>  - MARK the packets based on the OWNER match extension.  To do this 
> Asterisk would need to run as it''s own user, which should not be a
> problem.
I tried the owner match thing, maybe I did it wrong, but I end up with 
the same type of problems. When Asterisk needs to send traffic to WAN, 
it seem to bind to one of the two WAN IPs at random, and I end up with 
the same NATing problems when it chooses the wrong interface/IP. I also 
tried to inverse that: MARK all packets that are not Asterisk, put a 
special rule/table for that traffic and configure "default" (from all)
routing table to only one WAN interface. I''m not 100% sure if i did it 
correctly, but do you think it''s worth trying again?

Maybe this could be the type of solution I''m looking for if only i knew
a little more about that. Do you know how a process chooses an IP when 
binding to 0.0.0.0? Is the kernel doing this, and how/when? Maybe I 
could cheat in that case, and make Asterisk or the kernel or whichever 
does the binding think that there is only one WAN interface.

Also do you think that I could use some help from the netfilter SIP 
helper? I didn''t try but I think it would probably do the same.
> Grant. . . .
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
Thanks a lot for your time,
François....

Andrew McGill wrote:
> On Tuesday Dec 12, 2006 around 3:44pm, François Delawarde wrote,
>
>> Hello all,
>>
>> I have a linux machine with a SIP server (Asterisk) and 2 WAN 
>> interfaces (NATed) configured to do load balancing. I experienced 
>> problems with the SIP/RTP protocols and load balancing, because when 
>> initiating a call to an external SIP Host, a new RTP flow starts from 
>> the server to the Host, that sometimes uses another default route 
>> (due to the nexthop configuration). As i have two different public 
>> IPs, the external host gets confused while receiving flows from 
>> different IPs, and doesn''t work (or sometimes we only have
one-way
>> communication).
>
> There is a similar problem with openvpn which the --multihome patch in 
> 2.1_rc* solves (SOL_IP / IP_PKTINFO option on the socket).  Unless the 
> application (asterisk in your case) chooses to bind a UDP socket to a 
> particular IP address, the routing subsystem will assign the IP 
> address.  Since UDP is connectionless, there is no reason to use the 
> same IP address as the incoming ''connection''. 
(ip_conntrack doesn''t
> count.)
I cannot bind Asterisk to a particular IP address, as I need to use it 
for both LAN and WAN, but if the routing subsystem assigns the IP, does 
it take into account netfilter MARK and special rules, or do you know a 
way to "force" this routing subsystem into assigning an IP address?

I''m trying to understand when and how this IP address is chosen, and
see
if I can act at that level (doing NAT and ROUTE things doesn''t seem to 
work a lot, and it''s probably too "late" to work the problem.

>
> *You* may be able to solve the problem with some creative use of the 
> CONNMARK target (I didn''t succeed). The best solution, in the
absence
> of a kernel hack to treat UDP as a connection-oriented protocol, is to 
> fix asterisk (IMHO, IANAKH).
>
> &:-)
I was thinking of trying that along with the netfilter SIP helper, but I 
don''t even understand how helpers work yet. If you have an idea of how
i
could use those things, it would also be worth trying.


Thank you very much,
François.

François Delawarde wrote:
> Thank you for suggestions, below are my comments:
You are welcome.
> It''s actually the first thing i tried, but as I need to offer
service to
> both WAN and LAN, and the Asterisk SIP cannot bind to multiple IPs. It 
> only offers to bind it to a unique IP or 0.0.0.0 (and from the feedback 
> i got, they don''t intend to implement that any time soon). I could
> probably run multiple instances or implement this myself, but I
don''t
> have that much talent and time to do those complicated things. :-)
Um, I''m going to have to disagree with you.  I have run Asterisk in the
past (in production) where it would bind to multiple IPs.  The only 
caveat that I can think of is that it may only bind to one IP in a 
subnet, or some other strangeness with this.  ....  I just logged in to 
a colleague''s system that is running Asterisk for about 4 different 
subnets on one system.  Asterisk is bound to 0.0.0.0 so that it can 
serve any and all subnets.  If you would like help configuring Asterisk 
bind to multiple subnets let me know (via direct email) and I''ll be
glad
to try to help.
> I tried the owner match thing, maybe I did it wrong, but I end up with 
> the same type of problems. When Asterisk needs to send traffic to WAN, 
> it seem to bind to one of the two WAN IPs at random, and I end up with 
> the same NATing problems when it chooses the wrong interface/IP. I also 
> tried to inverse that: MARK all packets that are not Asterisk, put a 
> special rule/table for that traffic and configure "default" (from
all)
> routing table to only one WAN interface. I''m not 100% sure if i
did it
> correctly, but do you think it''s worth trying again?
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.
> Maybe this could be the type of solution I''m looking for if only i
knew
> a little more about that. Do you know how a process chooses an IP when 
> binding to 0.0.0.0? Is the kernel doing this, and how/when? Maybe I 
> could cheat in that case, and make Asterisk or the kernel or whichever 
> does the binding think that there is only one WAN interface.
As I understand it, when processes let the system choose the proper IP 
to use, the system will chose the IP that is associate with the closest 
route to the destination.  In short, if the target is on Subnet A, then 
the IP for Subnet A will be used.  If the target is on Subnet B, then 
the IP for Subnet B will be used.
> Also do you think that I could use some help from the netfilter SIP 
> helper? I didn''t try but I think it would probably do the same.
I''m not familiar with the SIP connection tracking helper.  However, I
do
believe it would be worth your time to investigate it to see if it will 
help you.  If you do continue to SNAT / MASQUERADE your outbound SIP 
traffic, there is a good chance that the SIP helper will indeed help. 
This is of course presuming that the SIP helper is meant to help the 
SNAT / MASQUERADE module correctly choose the information that gets put 
in to packets.  Think about how the FTP connection tracking helper works 
when dealing with active / passive data streams and ports.



Grant. . . .

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. . . .

Rangi Biddle wrote:
> What do you think of perhaps Francois using SER?
Well, I don''t have a problem with SIP Express Router and / or / verses 
Asterisk (or any other SIP Soft Switch for that matter), however, I 
think the OP will still be facing the same problem.

That problem being binding a daemon to a single IP address and routing 
traffic to / from it with out messing up the packets.  I am going to 
presume that Asterisk and / or SER will only be bound to a specific 
interface, not all of them.  I''m not sure why the OP only wants to bind
Asterisk to a single interface verses all of them, though I''m going to 
guess that s/he has a good reason for doing so.

It may be a case that Asterisk as the soft switch should be bound to the 
internal interface and SER bound to the external interface.  This way, 
the SIP traffic can be passed through both interfaces natively, via both 
daemons.  However, I think this would be more undo complexity for very 
little gain.



Grant. . . .

Rangi Biddle wrote:
> I was thinking more along the lines of using SER as a proxy that would
proxy
> the WAN connections to Asterisk.  Without knowing the number of connections
> Francois is expecting to receive on the WAN interface it may or may not be
> the solution to his issue and but if he does have a large amount of
> connections it would allow him to scale the system as needed by installing
> more SER systems.
*nod*

Now you are talking more about the scalability of a Linux based VoIP 
solution, which is beyond the scope of the LARTC.  Granted, LARTC will 
have a role in such a solution, but that role is just one small piece of 
the over all much larger solution.



Grant. . . .

François Delawarde wrote:
> I was thinking of trying that along with the netfilter SIP helper, but I
> don''t even understand how helpers work yet. If you have an idea of
how i
> could use those things, it would also be worth trying.
Just load ip_nat_sip, it should adjust the SDP information according to
the NATing done on the connection. You need to make sure though that
the RTP stream really does use the same connection (and NAT) as the
SIP connection, which is best done by using CONNMARK and fwmark based
routing.

I unfortunately think that I can''t use that solution (if I understood
it
well).

My box actually has two functions, it''s an Asterisk box and a load 
balancing router.

For LAN clients, as this box represents their default gateway, there 
would be no problem in implementing a pure routing solution. I could 
create a new subnet on a dummy interface, and reconfigure all LAN SIP 
phones to point to that IP, the box itself would route packets to its 
dummy interface.

For WAN clients, what I need is to have a unique interface (a unique 
public IP) accepting SIP connections, and outgoing traffic always 
passing by this interface. My current issue is with outgoing SIP/RTP 
traffic that sometimes gets load-balanced and uses the other public IP, 
which i have to force to the other interface, with lots of 
NATing/Re-Routing problems, as a single call can have multiple UDP flows 
(SIP and RTPs).

My main problem with the DummyNet solution on the WAN side is that I 
cannot access to the internet routers behind this box, so I can''t add 
routes to reach a new subnet. This means that I''m back with the same 
type of problem trying to NAT, but this time not only the box''s
outgoing
traffic, but also the clients incoming traffic, for them to reach the 
dummy0 interface.

Tell me if i''m wrong, but that solutions appears to me as more 
complicated in my particular case. Aouch, that''s much harder than I 
thought it would be. :-(

François.


Grant Taylor wrote:
> 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
>

I have ip_nat_sip compiled in the kernel (and not as a module). Is that 
an issue?

Could you give me an example of how I could do using CONNMARK and fwmark 
based routing if I have an outgoing RTP flow bound to the wrong interface?

Thanks a lot,
François.

Patrick McHardy wrote:
> François Delawarde wrote:
>> I was thinking of trying that along with the netfilter SIP helper, but
I
>> don''t even understand how helpers work yet. If you have an
idea of how i
>> could use those things, it would also be worth trying.
>
> Just load ip_nat_sip, it should adjust the SDP information according to
> the NATing done on the connection. You need to make sure though that
> the RTP stream really does use the same connection (and NAT) as the
> SIP connection, which is best done by using CONNMARK and fwmark based
> routing.
>
>