Re: why can't I DNAT SIP?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



sean darcy wrote:
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


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.


--
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

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux