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.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
