Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: iptables: User

UDP port redirect

 

 

iptables user RSS feed   Index | Next | Previous | View Threaded


thiago at powers

Jul 31, 2007, 4:04 PM

Post #1 of 5 (1137 views)
Permalink
UDP port redirect

Hello all,

I got a problem when redirecting a UDP port. The rules are:

# TCP port redirect - working fine:

iptables -t nat -A PREROUTING -i <ext_if> -p tcp -d <ext_ip> --dport 22 -j
DNAT -m state --state NEW --to <int_ip>:1194
iptables -A FORWARD -i <ext_if> -p tcp -d <int_ip> --dport 1194 -m state
--state NEW -j ACCEPT

# UDP port redirect - not going through

iptables -t nat -A PREROUTING -i <ext_if> -p udp -d <ext_ip> --dport 22 -j
DNAT -m state --state NEW --to <int_ip>:1194
iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -m state
--state NEW -j ACCEPT

I hit the nat/prerouting rule, but never reach the filter/forward one.
As you can see the only change I've made from the tcp rule to udp rule, is
just the matching protocol.
I can debug it a little more, but also would like to hear from you guys if
you have any hints.

iptables v1.3.8
2.6.16.36-default

Thanks !

Thiago.


m at rtij

Jul 31, 2007, 11:07 PM

Post #2 of 5 (1075 views)
Permalink
Re: UDP port redirect [In reply to]

thiago [at] powers wrote:
> Hello all,
>
> I got a problem when redirecting a UDP port. The rules are:
>
> # TCP port redirect - working fine:
>
> iptables -t nat -A PREROUTING -i <ext_if> -p tcp -d <ext_ip> --dport 22 -j
> DNAT -m state --state NEW --to <int_ip>:1194
> iptables -A FORWARD -i <ext_if> -p tcp -d <int_ip> --dport 1194 -m state
> --state NEW -j ACCEPT
>
> # UDP port redirect - not going through
>
> iptables -t nat -A PREROUTING -i <ext_if> -p udp -d <ext_ip> --dport 22 -j
> DNAT -m state --state NEW --to <int_ip>:1194
> iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -m state
> --state NEW -j ACCEPT
>
> I hit the nat/prerouting rule, but never reach the filter/forward one.
> As you can see the only change I've made from the tcp rule to udp rule, is
> just the matching protocol.
> I can debug it a little more, but also would like to hear from you guys if
> you have any hints.
>

Not sure why this doesn't work, but you don't need the state match in
the NAT rule.

iptables -t nat -A PREROUTING -i <ext_if> -p udp -d <ext_ip> --dport 22 -j DNAT --to <int_ip>:1194
iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -m state --state NEW -j ACCEPT


should work.

You may want to add an explicit LOG rule:

iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -j LOG --log-prefix "WRONG: "

or even

iptables -A FORWARD -p udp --dport 1194 -j LOG --log-prefix "WRONG: "


after the ACCEPT rule to debug this.

M4


casper at meteor

Aug 1, 2007, 12:05 AM

Post #3 of 5 (1091 views)
Permalink
Re: UDP port redirect [In reply to]

В Вто, 31/07/2007 в 20:04 -0300, thiago [at] powers пишет:
> Hello all,
>
> I got a problem when redirecting a UDP port. The rules are:
>
> # TCP port redirect - working fine:
>
> iptables -t nat -A PREROUTING -i <ext_if> -p tcp -d <ext_ip> --dport 22 -j
> DNAT -m state --state NEW --to <int_ip>:1194
> iptables -A FORWARD -i <ext_if> -p tcp -d <int_ip> --dport 1194 -m state
> --state NEW -j ACCEPT

"-m state --state NEW" - what is this for? Nat table only sees packets
initiating connection, isn't it?

> # UDP port redirect - not going through
>
> iptables -t nat -A PREROUTING -i <ext_if> -p udp -d <ext_ip> --dport 22 -j
> DNAT -m state --state NEW --to <int_ip>:1194
> iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -m state
> --state NEW -j ACCEPT

You accepting NEW packets in filter table, consider make sure rest would
pass through.

> I hit the nat/prerouting rule, but never reach the filter/forward one.
> As you can see the only change I've made from the tcp rule to udp rule, is
> just the matching protocol.
> I can debug it a little more, but also would like to hear from you guys if
> you have any hints.

Also, I've experiensed situation for UDP when nat rules doesn't match because
there was such connection before the rule inserted and conntrack already saw
it and has it counted. UDP connection tracking (since it's a connectionless
protocol) goes by src/dst ports. Packets can belong to different
"connections". The solution for me was to stop UDP connection for several
minutes to make conntrack forget it and then try again.

> iptables v1.3.8
> 2.6.16.36-default
>
> Thanks !
>
> Thiago.
>
>
>
--
Покотиленко Костик <casper [at] meteor>


thiago at powers

Aug 1, 2007, 5:52 AM

Post #4 of 5 (1079 views)
Permalink
Re: UDP port redirect [In reply to]

Покотиленко Костик <casper [at] meteor> gravou em 01/08/2007 04:05:05:

> В Вто, 31/07/2007 в 20:04 -0300, thiago [at] powers пишет:
> > Hello all,
> >
> > I got a problem when redirecting a UDP port. The rules are:
> >
> > # TCP port redirect - working fine:
> >
> > iptables -t nat -A PREROUTING -i <ext_if> -p tcp -d <ext_ip> --dport
22 -j
> > DNAT -m state --state NEW --to <int_ip>:1194
> > iptables -A FORWARD -i <ext_if> -p tcp -d <int_ip> --dport 1194 -m
state
> > --state NEW -j ACCEPT
>
> "-m state --state NEW" - what is this for? Nat table only sees packets
> initiating connection, isn't it?

You got it right, there's no need for that. I made that change in a
previous search & replace.. forget about it.


>
> > # UDP port redirect - not going through
> >
> > iptables -t nat -A PREROUTING -i <ext_if> -p udp -d <ext_ip> --dport
22 -j
> > DNAT -m state --state NEW --to <int_ip>:1194
> > iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -m
state
> > --state NEW -j ACCEPT
>
> You accepting NEW packets in filter table, consider make sure rest would
> pass through.

Good remind, but it is stateful, for sure.

>
> > I hit the nat/prerouting rule, but never reach the filter/forward one.
> > As you can see the only change I've made from the tcp rule to udp
rule, is
> > just the matching protocol.
> > I can debug it a little more, but also would like to hear from you
guys if
> > you have any hints.
>
> Also, I've experiensed situation for UDP when nat rules doesn't match
because
> there was such connection before the rule inserted and conntrack already
saw
> it and has it counted. UDP connection tracking (since it's a
connectionless
> protocol) goes by src/dst ports. Packets can belong to different
> "connections". The solution for me was to stop UDP connection for
several
> minutes to make conntrack forget it and then try again.

Had the same (not pleasant) experience with that before, too. Conntrack
tunables in /proc/sys/net/ipv4/netfilter/ helped me a lot.


Thanks anyway !


thiago at powers

Aug 1, 2007, 5:52 AM

Post #5 of 5 (1074 views)
Permalink
Re: UDP port redirect [In reply to]

Hello Martijn,


Martijn Lievaart <m [at] rtij> gravou em 01/08/2007 03:07:23:

> Not sure why this doesn't work, but you don't need the state match in
> the NAT rule.

That state match in nat/prerouting, my mistake.. it shouldn't be there.
But I don't believe that was the problem, as it just does nothing..

> iptables -t nat -A PREROUTING -i <ext_if> -p udp -d <ext_ip> --dport
> 22 -j DNAT --to <int_ip>:1194
> iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -m
> state --state NEW -j ACCEPT
>
> should work.

It should ! :-)

>
> You may want to add an explicit LOG rule:
>
> iptables -A FORWARD -i <ext_if> -p udp -d <int_ip> --dport 1194 -j
> LOG --log-prefix "WRONG: "
>
> or even
>
> iptables -A FORWARD -p udp --dport 1194 -j LOG --log-prefix "WRONG: "


The connection never goes through :/

fw:/etc/iptables # iptables -t nat -L PREROUTING -n -v | grep -E
'udp.*22.*1194'
1 70 DNAT udp -- eth0 * 0.0.0.0/0 <ext_ip> udp
dpt:22 to:192.168.10.254:1194

fw:/etc/iptables # iptables -L FORWARD -n -v | grep -E 'LOG.*udp.*1194'
0 0 LOG udp -- eth0 * 0.0.0.0/0 192.168.10.254
udp dpt:1194 LOG flags 0 level 4 prefix `WRONG: '

>
>
> after the ACCEPT rule to debug this.
>
> M4
>
>

iptables user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.