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. > >
Possibly Parallel Threads
- multiple routing tables for internal router programs
- Route all LAN traffic through eth2 and keep web/mail traffic on eth0
- Routing through dummy interfaces?
- Two routing cache entries with different interface
- Q: Routing the Same IP simultaneously on different computers ?