why can't I DNAT SIP?

why can't I DNAT SIP?

[sean darcy]

On my outside box I trying to route sip ( port 5060 ) and iax ( 4659 ) 
packets to an internal asterisk server. I use DNAT, which works fine for 
  iax, but doesn't for SIP. I'm using identical DNAT statments.

The log shows the SIP packets coming in, but then going to the INPUT 
chain. Nothing shows up on the FORWARD chain.

iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 168K packets, 17M bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 DNAT       udp  --  external *       0.0.0.0/0 
0.0.0.0/0           udp dpt:4569 to:10.10.10.180:4569
     0     0 DNAT       udp  --  external *       0.0.0.0/0 
0.0.0.0/0           udp dpts:10000:10100 to:10.10.10.180
     0     0 DNAT       udp  --  external *       0.0.0.0/0 
0.0.0.0/0           udp dpt:5060 to:10.10.10.180:5060

Chain POSTROUTING (policy ACCEPT 3098 packets, 298K bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 LOG        udp  --  *      lan     0.0.0.0/0 
0.0.0.0/0           udp dpt:5060 LOG flags 0 level 4 prefix `SIP-POST: '
     5   268 SNAT       all  --  *      external  0.0.0.0/0 
0.0.0.0/0           to:xxx.yyy.zzz.ooo


IPT=/sbin/iptables

# first, flush all chains
/sbin/iptables  -F
/sbin/iptables -t nat -F
$IPT  -t raw -F
/sbin/iptables  -X

# log SIP packets

$IPT -t raw -A PREROUTING -p udp --dport 5060 -s ext-box -j LOG 
--log-prefix "GATEWAY:   "
$IPT  -A FORWARD -p udp --dport 5060 -s ext-box  -j LOG --log-prefix 
"SIP-FWD:    "
$IPT  -A INPUT -p udp --dport 5060 -s ext-box  -j LOG --log-prefix 
"SIP-INPUT:    "
$IPT -t nat -A POSTROUTING -s 76.248.148.160 -p udp --dport 5060  -j LOG 
--log-prefix "SIP-POST: "

##  DNAT iax packets

$IPT -t nat -A PREROUTING -i external -p udp --dport 4569 -j DNAT --to 
10.10.10.180:4569
$IPT -A FORWARD -p udp -m state --state NEW -d 10.10.10.180 --dport 4569 
-j ACCEPT

# this should do the same for sip

$IPT -t nat -A PREROUTING -s ext-box  -p udp --dport 5060 -j DNAT --to 
10.10.10.180:5060
$IPT -A FORWARD -p udp --dport 5060 -m state --state NEW -d 10.10.10.180 
-j ACCEPT

.............

The log shows SIP packets both at GATEWAY and SIP-INPUT.

Any help appreciated.

sean

Re: why can't I DNAT SIP?

[Grant Taylor]

On 05/07/08 20:10, sean darcy wrote:
> On my outside box I trying to route sip ( port 5060 ) and iax ( 4659 ) 
> packets to an internal asterisk server. I use DNAT, which works fine for 
> iax, but doesn't for SIP. I'm using identical DNAT statments.

No you are not.

> $IPT -t nat -A PREROUTING -i external -p udp --dport 4569 -j DNAT --to 
> 10.10.10.180:4569

(verses)

> $IPT -t nat -A PREROUTING -s ext-box  -p udp --dport 5060 -j DNAT --to 
> 10.10.10.180:5060

Note that you have "-i external" on the first (IAX) rule and "-s 
ext-box" on the second (SIP) rule.

I don't know if you have taken this in to account or not, but remember 
that SIP is not really NAT friendly.



Grant. . . .

Re: why can't I DNAT SIP?

[sean darcy]

Grant Taylor wrote:
> On 05/07/08 20:10, sean darcy wrote:
>> On my outside box I trying to route sip ( port 5060 ) and iax ( 4659 ) 
>> packets to an internal asterisk server. I use DNAT, which works fine 
>> for iax, but doesn't for SIP. I'm using identical DNAT statments.
> 
> No you are not.
> 
>> $IPT -t nat -A PREROUTING -i external -p udp --dport 4569 -j DNAT --to 
>> 10.10.10.180:4569
> 
> (verses)
> 
>> $IPT -t nat -A PREROUTING -s ext-box  -p udp --dport 5060 -j DNAT --to 
>> 10.10.10.180:5060
> 
> Note that you have "-i external" on the first (IAX) rule and "-s 
> ext-box" on the second (SIP) rule.
> 
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.

> I don't know if you have taken this in to account or not, but remember 
> that SIP is not really NAT friendly.
> 

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?

Here it comes in -t raw -A PREROUTING:

GATEWAY:   IN=external OUT= 
MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=xxx.yyy.148.160 
DST=yyy.xxx.167.178 LEN=527 TOS=0x04 PREC=0x00 TTL=48 ID=32417 PROTO=UDP 
SPT=5060 DPT=5060 LEN=507

either:
$IPT -t nat -A PREROUTING -s ext-box  -p udp --dport 5060 -j DNAT --to
10.10.10.180:5060

or:

$IPT -t nat -A PREROUTING -i external -p udp --dport 5060 -j DNAT --to 
10.10.10.180:5060

should send the packet to the FORWARD chain, but instead it shows up in 
INPUT:

SIP-INPUT:    IN=external OUT= 
MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=xxx.yyy.148.160 
DST=yyyy.xxx.167.178 LEN=527 TOS=0x04 PREC=0x00 TTL=48 ID=32417 
PROTO=UDP SPT=5060 DPT=5060 LEN=507


?????

Re: why can't I DNAT SIP?

[Mike Wright]

sean darcy wrote:
> On my outside box I trying to route sip ( port 5060 ) and iax ( 4659 ) 
> packets to an internal asterisk server. I use DNAT, which works fine for 
>  iax, but doesn't for SIP. I'm using identical DNAT statments.
> 
> The log shows the SIP packets coming in, but then going to the INPUT 
> chain. Nothing shows up on the FORWARD chain.
> 
> iptables -L -n -v -t nat
> Chain PREROUTING (policy ACCEPT 168K packets, 17M bytes)
>  pkts bytes target     prot opt in     out     source destination
>     0     0 DNAT       udp  --  external *       0.0.0.0/0 
> 0.0.0.0/0           udp dpt:4569 to:10.10.10.180:4569
>     0     0 DNAT       udp  --  external *       0.0.0.0/0 
> 0.0.0.0/0           udp dpts:10000:10100 to:10.10.10.180
>     0     0 DNAT       udp  --  external *       0.0.0.0/0 
> 0.0.0.0/0           udp dpt:5060 to:10.10.10.180:5060
> 
> Chain POSTROUTING (policy ACCEPT 3098 packets, 298K bytes)
>  pkts bytes target     prot opt in     out     source destination
>     0     0 LOG        udp  --  *      lan     0.0.0.0/0 
> 0.0.0.0/0           udp dpt:5060 LOG flags 0 level 4 prefix `SIP-POST: '
>     5   268 SNAT       all  --  *      external  0.0.0.0/0 
> 0.0.0.0/0           to:xxx.yyy.zzz.ooo
>

I've found it very helpful to look at the rules as output by the command
"iptables-save".  It's formatted nicely and in order of evaluation.  If
there are errors they are easier to spot (at least for me).

my 2p

Re: why can't I DNAT SIP?

[sean darcy]

sean darcy wrote:
> Grant Taylor wrote:
>> On 05/07/08 20:10, sean darcy wrote:
>>> On my outside box I trying to route sip ( port 5060 ) and iax ( 4659 
>>> ) packets to an internal asterisk server. I use DNAT, which works 
>>> fine for iax, but doesn't for SIP. I'm using identical DNAT statments.
>>
>> No you are not.
>>
>>> $IPT -t nat -A PREROUTING -i external -p udp --dport 4569 -j DNAT 
>>> --to 10.10.10.180:4569
>>
>> (verses)
>>
>>> $IPT -t nat -A PREROUTING -s ext-box  -p udp --dport 5060 -j DNAT 
>>> --to 10.10.10.180:5060
>>
>> Note that you have "-i external" on the first (IAX) rule and "-s 
>> ext-box" on the second (SIP) rule.
>>
> 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.
> 
>> I don't know if you have taken this in to account or not, but remember 
>> that SIP is not really NAT friendly.
>>
> 
> 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?
> 
> Here it comes in -t raw -A PREROUTING:
> 
> GATEWAY:   IN=external OUT= 
> MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=xxx.yyy.148.160 
> DST=yyy.xxx.167.178 LEN=527 TOS=0x04 PREC=0x00 TTL=48 ID=32417 PROTO=UDP 
> SPT=5060 DPT=5060 LEN=507
> 
> either:
> $IPT -t nat -A PREROUTING -s ext-box  -p udp --dport 5060 -j DNAT --to
> 10.10.10.180:5060
> 
> or:
> 
> $IPT -t nat -A PREROUTING -i external -p udp --dport 5060 -j DNAT --to 
> 10.10.10.180:5060
> 
> should send the packet to the FORWARD chain, but instead it shows up in 
> INPUT:
> 
> SIP-INPUT:    IN=external OUT= 
> MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=xxx.yyy.148.160 
> DST=yyyy.xxx.167.178 LEN=527 TOS=0x04 PREC=0x00 TTL=48 ID=32417 
> PROTO=UDP SPT=5060 DPT=5060 LEN=507
> 
> 
> ?????
> 
AFAICS, ports 4569 and 5060 should both be FORWARD'ed:

+ /sbin/iptables -v -t nat -A PREROUTING -i external -p udp --dport 4569 
-j DNAT --to 10.10.10.180:4569
DNAT  udp opt -- in external out *  0.0.0.0/0  -> 0.0.0.0/0  udp 
dpt:4569 to:10.10.10.180:4569
+ /sbin/iptables -v -A FORWARD -p udp -m state --state NEW -d 
10.10.10.180 --dport 4569 -j ACCEPT
ACCEPT  udp opt -- in * out *  0.0.0.0/0  -> 10.10.10.180  state NEW udp 
dpt:4569
+ /sbin/iptables -v -t nat -A PREROUTING -i external -p udp --dport 5060 
-j DNAT --to 10.10.10.180:5060
DNAT  udp opt -- in external out *  0.0.0.0/0  -> 0.0.0.0/0  udp 
dpt:5060 to:10.10.10.180:5060
+ /sbin/iptables -v -A FORWARD -p udp --dport 5060 -m state --state NEW 
-d 10.10.10.180 -j ACCEPT
ACCEPT  udp opt -- in * out *  0.0.0.0/0  -> 10.10.10.180  udp dpt:5060 
state NEW

sean

Re: why can't I DNAT SIP?

[Grant Taylor]

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.



Grant. . . .

Re: why can't I DNAT SIP?

[Patrick McHardy]

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?

- What helpers are loaded (both NAT and conntrack)

- How does the entry from /proc/net/nf_conntrack for the
   SIP connection look like?

Re: why can't I DNAT SIP?

[sean darcy]

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

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

Re: why can't I DNAT SIP?

[Jan Engelhardt]

On Saturday 2008-05-10 04:04, sean darcy wrote:
>>
>> - 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

I would have expected to find nf_nat_sip here.

Re: why can't I DNAT SIP?

[sean darcy]

Jan Engelhardt wrote:
> On Saturday 2008-05-10 04:04, sean darcy wrote:
>>> - 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
> 
> I would have expected to find nf_nat_sip here.
> --

I've seen references to nf_nat_sip, but no docs, howto or examples. What 
does it do that simple port forwarding doesn't? and how do you use it?

sean

Re: why can't I DNAT SIP?

[Jan Engelhardt]

On Sunday 2008-05-11 16:53, sean darcy wrote:
>
> I've seen references to nf_nat_sip, but no docs, howto or examples. What does
> it do that simple port forwarding doesn't? and how do you use it?

It modifies the SIP packets to contain the correct address when you
happen to NAT connections.

Re: why can't I DNAT SIP?

[sean darcy]

Jan Engelhardt wrote:
> On Sunday 2008-05-11 16:53, sean darcy wrote:
>> I've seen references to nf_nat_sip, but no docs, howto or examples. What does
>> it do that simple port forwarding doesn't? and how do you use it?
> 
> It modifies the SIP packets to contain the correct address when you
> happen to NAT connections.
> --

Any examples on how to use it?

I even went and read the source. Sigh.

sean

Re: why can't I DNAT SIP?

[Jan Engelhardt]

On Sunday 2008-05-11 20:02, sean darcy wrote:
> Jan Engelhardt wrote:
>> On Sunday 2008-05-11 16:53, sean darcy wrote:
>> > I've seen references to nf_nat_sip, but no docs, howto or examples. What
>> > does
>> > it do that simple port forwarding doesn't? and how do you use it?
>> 
>> It modifies the SIP packets to contain the correct address when you
>> happen to NAT connections.
>
> Any examples on how to use it?

Just load it.

Re: why can't I DNAT SIP?

[Patrick McHardy]

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.