Re: : sipxecs behind NAT
Dave Cramer <[email protected]>
| Newsgroups | gmane.org.user-groups.linux.tolug |
|---|---|
| Message-ID | <CADK3HH+ZoFPqa3BWKo26nZVtsT7NK2eGSpvYD27VjW1QupasXQ@mail.gmail.com> |
On Thu, Mar 20, 2014 at 12:19 PM, Lennart Sorensen < lsorense-1wCw9BSqJbv44Nm34jS7GywD8/[email protected]> 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/[email protected]> 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 > >