Re: why can't I DNAT SIP?

[Patrick McHardy <kaber@trash.net>]

sean darcy wrote:
> On Fri, May 9, 2008 at 10:23 AM, Patrick McHardy <kaber@trash.net> wrote:
>> Grant Taylor wrote:
>>> On 05/08/08 17:24, sean darcy wrote:
>>>> I tried it both ways. FWIW, it works both ways for iax. I showed it that
>>>> way because the LOG statement were that way. I've run them all both ways.
>>>>
>>>> Yeah, but why is iptables not filtering the packet correctly; it's just a
>>>> port 5060 udp packet. How can it matter that it's 5060 instead of 4569?
>>> With out knowing the full scenario, I can't say for sure.  Are you dealing
>>> with an on going established connection, thus one that is not passing
>>> through the NAT chain again?
>>>
>>> Is it possible that you are dealing with SIP Reinvited traffic that really
>>> has a source of elsewhere?
>>>
>>> More things are starting to come in to play.
>> Some questions that might help answering this:
>>
>> - Which kernel version are you running?
> 
> 2.6.22
>> - What helpers are loaded (both NAT and conntrack)
> 
> ?? How would I find out? If you mean modules:
> 
> lsmod | grep nat
> iptable_nat            11461  1
> nf_nat                 22381  1 iptable_nat
> nf_conntrack_ipv4      21837  5 iptable_nat
> nf_conntrack           64585  4 xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
> nfnetlink               9945  3 nf_nat,nf_conntrack_ipv4,nf_conntrack
> ip_tables              16517  3 iptable_raw,iptable_nat,iptable_filter
> x_tables               18629  5 xt_state,ipt_LOG,xt_tcpudp,iptable_nat,ip_tables
>> - How does the entry from /proc/net/nf_conntrack for the
>>  SIP connection look like?
>>
> 
> OK. It's sunspots. Just got back to this now, and it's working:
> 
> GATEWAY:   IN=external OUT=
> MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=xxx.yyy.144.110
> DST=yyy.xxx.167.178 LEN=576 TOS=0x04 PREC=0x00 TTL=49 ID=8130
> PROTO=UDP SPT=5060 DPT=5060 LEN=556
> SIP-FWD:    IN=external OUT=lan SRC=xxx.yyy.144.110 DST=10.10.10.180
> LEN=576 TOS=0x04 PREC=0x00 TTL=48 ID=8130 PROTO=UDP SPT=5060 DPT=5060
> LEN=556


That would indicate that a conntrack entry already existed when
the first packet arrived from the outside. I'm guessing that it
arrived before the DNAT rules were set up. Adding:

conntrack -F

to the end of your firewall-script should make sure that it works
reliably.