sipxecs behind NAT

Dave Cramer davecramer-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Thu Mar 20 16:33:20 UTC 2014


On Thu, Mar 20, 2014 at 12:19 PM, Lennart Sorensen <
lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:

> On Thu, Mar 20, 2014 at 11:57:22AM -0400, Dave Cramer wrote:
> > On Thu, Mar 20, 2014 at 11:45 AM, Lennart Sorensen <
> > lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> >
> > > On Thu, Mar 20, 2014 at 11:44:33AM -0400, Dave Cramer wrote:
> > > > This is my masquerade rule:
> > > >
> > > > MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24
> > > >
> > > > I'm curious why sipxecs would even put the internal IP in the packet
> ?
> > >
> > > Do you have the sip conntrack helper module loaded on your router?
> > >
> > > SIP is one of the protocols that needs help to go through nat, because
> > > the packets include internal IPs in them.
> > >
> > > Len,
> >
> > I didn't but I just loaded them with similar results
>
> You may have to reboot the router (or somehow flush the connection
> tracking table) to make it forget about any existing connection attempts.
>
> Of course some sip phones are "broken" or at least weird and unusual
> and don't work well with the sip nat handling in the kernel (generally
> things made by Cisco, but only a few models).
>
> The modules should be nf_nat_sip and nf_conntrack_sip.
>

Ya I think it could be the phone, and the "router" is a linux box so
flushing the tracking table should be possible

Thanks,

Dave

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20140320/668b78ca/attachment.html>


More information about the Legacy mailing list