On Fri, May 9, 2008 at 10:23 AM, Patrick McHardy <kaber@xxxxxxxxx> 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 Thanks for all the help. I certainly know a lot more about debugging iptables. FWIW, here's the entry from /proc/net/nf_conntrack: ipv4 2 udp 17 161 src=xxx.yyy.144.110 dst=yyy.xxx.167.178 sport=5060 dport=5060 packets=1288 bytes=693472 src=10.10.10.180 dst=xxx.yyy.144.110 sport=5060 dport=5060 packets=1783 bytes=884951 [ASSURED] mark=0 secmark=0 use=1 Is this telling me there's an ESTABLISHED connection? So somehow a sip packet that was NEW got in, and the ACK made iptables set it up? If so, it works now as long as they keep ACKing each other, but if I try a new sip connection, for instance from the road, I'll have the same issue? sean -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
