conntrack and application-triggered port forwarding

conntrack and application-triggered port forwarding

[marian stagarescu]

i may be missing something elementary about conntrack & nat & firewall
so please let me know if the following feature is supported in linux
because i don't quite see it:

outside the scope of specialized ALGs (e.g. ftp, h323,...) i want 
to be able to specify that an outbound tcp/udp connection to dstport x
will require that related traffic be allowed inbound on port y.

that is to say, for a gateway:

NET---| NAT/Conntrack/Firewall |---(private LAN)

_IF_AND_ONLY_IF_ traffic goes from LAN on tcp/dstport X open
forward chain to allow related udp/dstport Y to go back on LAN.
(i have a drop policy on forward chain for traffic with input interface
facing NET).

in this example the tcp traffic will be playing the role of the control
channel and the udp the data channel but since I know that it operates
on predefined ports (or port ranges) i don't have to snoop into the
control channel and get the data channel port.

this will be some "generic" ALG mechanism so that for applications that
are operating on known ports (or port ranges) i can use it without an
ALG implementation proper.

I can use static rules that will open udp/dstport Y but forward path
will be open on this rule (proto/port) regardless of the presence of
outbound tcp/dstport x traffic. so opening the firewall is not triggered
by an application.


Not being too familiar with the internals and api  of conntrack i
wonder: is such a task easy (example pointers ?)? 

the conntrack api is exposing methods for deleting/adding conntracks
entries. so theoretically speaking if i have a userland daemon that
talks via a netlink socket with conntrack (i played a bit with
ctnetlink) i can get notification on outgoing traffic, match it against
such "rule" and inject into conntrack "related" tuples that will match
the incoming response. is there a (better) way to do this in kernel
space alone via iptables interface, e.g, here are 2 related rules, when
one matches traffic install the other one too, when it expires, remove
the related rule ? 

your input is appreciated.

thanks,
marian

Re: conntrack and application-triggered port forwarding

[Martijn Lievaart]

marian stagarescu wrote:

>i may be missing something elementary about conntrack & nat & firewall
>so please let me know if the following feature is supported in linux
>because i don't quite see it:
>
>outside the scope of specialized ALGs (e.g. ftp, h323,...) i want 
>to be able to specify that an outbound tcp/udp connection to dstport x
>will require that related traffic be allowed inbound on port y.
>
>that is to say, for a gateway:
>
>NET---| NAT/Conntrack/Firewall |---(private LAN)
>
>_IF_AND_ONLY_IF_ traffic goes from LAN on tcp/dstport X open
>forward chain to allow related udp/dstport Y to go back on LAN.
>(i have a drop policy on forward chain for traffic with input interface
>facing NET).
>
>in this example the tcp traffic will be playing the role of the control
>channel and the udp the data channel but since I know that it operates
>on predefined ports (or port ranges) i don't have to snoop into the
>control channel and get the data channel port.
>
>this will be some "generic" ALG mechanism so that for applications that
>are operating on known ports (or port ranges) i can use it without an
>ALG implementation proper.
>
>I can use static rules that will open udp/dstport Y but forward path
>will be open on this rule (proto/port) regardless of the presence of
>outbound tcp/dstport x traffic. so opening the firewall is not triggered
>by an application.
>
>
>Not being too familiar with the internals and api  of conntrack i
>wonder: is such a task easy (example pointers ?)? 
>  
>

The recent match should be able to do this.
1. Create a rule that matches the control channel and add the packet to 
a recent-table.
2. Match on the udp reverse packets. and on the reversed source/dest in 
the recent table. If match, accept.

Martijn

Re: conntrack and application-triggered port forwarding

[marian stagarescu]

> The recent match should be able to do this.
> 1. Create a rule that matches the control channel and add the packet to 
> a recent-table.
> 2. Match on the udp reverse packets. and on the reversed source/dest in 
> the recent table. If match, accept.
> 
> Martijn

hi martijn,

thanks for your input. a couple questions on this recent match patch
usage here:

for 1 above:

iptables -I FORWARD -o (NET_IFACE) -p tcp --dport 100 -m recent --name
test --set -j ACCEPT
 
will install src (LAN IP) in recent list

2) Not trying to set the accept for reverse:

iptables -I FORWARD -i (NET_IFACE) -p udp --dport 200 -m recent --name
test --rcheck 

will test against the src ip (NET IP) whereas i need dst ip (LAN IP)

thanks,
marian

Re: conntrack and application-triggered port forwarding

[Martijn Lievaart]

marian stagarescu wrote:

>>The recent match should be able to do this.
>>1. Create a rule that matches the control channel and add the packet to 
>>a recent-table.
>>2. Match on the udp reverse packets. and on the reversed source/dest in 
>>the recent table. If match, accept.
>>
>>Martijn
>>    
>>
>
>hi martijn,
>
>thanks for your input. a couple questions on this recent match patch
>usage here:
>
>for 1 above:
>
>iptables -I FORWARD -o (NET_IFACE) -p tcp --dport 100 -m recent --name
>test --set -j ACCEPT
> 
>will install src (LAN IP) in recent list
>
>2) Not trying to set the accept for reverse:
>
>iptables -I FORWARD -i (NET_IFACE) -p udp --dport 200 -m recent --name
>test --rcheck 
>
>will test against the src ip (NET IP) whereas i need dst ip (LAN IP)
>
>  
>

Mind you, you'll need a more recent (no pun intended) release of 
iptables than the current release, This functionality is not in iptables 
1.2.7a. Look at the homepage for recent 
(http://snowman.net/projects/ipt_recent/) for more information on how to 
use it, there are examples there. Also see my previous post and the 
answer from Stephen Frost (the author of the recent module) (Subject: 
Talking about recent (was: Re: [PATCH] 2.4.x new amanda conntrack + NAT 
support)).

Finally, this kind of questions really belongs on the user-list 
(although in this paprticular instance you where lucky you posted here). 
Please post question about usage of iptables there 
(netfilter@lists.netfilter.org).

HTH,
Martijn Lievaart