Eric Koome <[email protected]> wrote: > I had those modules are disabled. > > My thoughts are since both boxes are in the same LAN, how can I rewrite the > packets to be sent via eth1. That is from proxy's eth0 to other box eth1 to > be redirected via its eth1 interface.
NAT and SIP don't mix well, it's just one of many things that NAT breaks :-( By far the best way would be to put suitable rules in the SIP software packages to route packets directly OR to understand the NAT that's going on. For example, Asterisk has the ability to be told about the NAT environment and it'll put the public address/port in it's outbound packets, Ditto most end points (phones) - but unfortunately some NAT gateways (Xyxel for example) deliberately screw around in the NAT so this doesn't work. In the example you give, there are packets going from private (RFC1918) addresses to public addresses and vice-versa. Since SIP includes IP addresses inside the packets, you need to "pre mangle" these in your software so they come out right the other side of the NAT gateway. Using a SIP helper might seem attractive, but it has to do some guesswork as to what should and should not be changed. I work with IP telephony at work, our provider has a NAT proxy which basically ignores the IP/port on the SIP packets, and works out the real values when the client connects to it - and then forwards the "fixed" packets on to the servers. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
