unexpected problem with DNAT

unexpected problem with DNAT

[thingstocome]

hello,
i'm currently configuring a linux box to function as a router/gateway
between two different LAN networks.

default config:
Hosts from LAN_1 shall be able to connect to LAN_2 via masquerading (SNAT) 
which works fine, and hosts from LAN_2 shall only be able to connect to the
gateway,
not to any host in LAN_2.

However sometimes it is necessery that a host of LAN_2 initiates a
connection to a  
certain computer in LAN_1.

I do this by adding following rule to the gateways' iptables, which also
works fine:

iptables -t nat -A PREROUTING -j DNAT -i eth1 -d <GATEWAY_ADDR1> --to
<LAN_1_ADDR>

note: GATEWAY_ADDR1 ... is one of several ip addresses that belong to the
gateway,
        LAN_1_ADDR        ... is the address of host that shall be reached
from LAN_2.

ok now here's my problem:

i thought that i can deny access to LAN_1_ADDR again as soon as the
connection isnt needed anymore, by simply removing the rule.

this worked if there were no open connections between the hosts, but not if
the host in LAN_2 already had established one.

here an example:

I logon from LAN_2 to a ftp server in LAN_1 through the gateway via DNAT .
no problem.
Now i flush the prerouting chain, remove the rule, whatever.
DNAT should not be allowed now anymore.
But the host in LAN_2 still has an open ftp connection and has access to the
host in LAN_1 until the ftp session is over.

But this must not be possible, i want to avoid it .

I think the host can still be accessed because the connection tracking
module
still has the entries of the session stored.
I tried to "restart" the firewall ( -> flushed _all_ chains, & reset _all_
rules without dnat the rule) but the connection was still alive.

( if it interests you , new connections to LAN_1_ADDR couldnt be started of
course ).

Does anyone know how to solve this problem ?

i hope my explanation isnt too horrible.

thanks in advance

tC

PS:excuse my bad english, i'm not a native speaker



-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: unexpected problem with DNAT

[Jan Humme]

On Wednesday 10 July 2002 14:18, thingstocome@gmx.net wrote:
> hello,
> i'm currently configuring a linux box to function as a router/gateway
> between two different LAN networks.
>
> default config:
> Hosts from LAN_1 shall be able to connect to LAN_2 via masquerading (SNAT)
> which works fine, and hosts from LAN_2 shall only be able to connect to the
> gateway,
> not to any host in LAN_2.
>
> However sometimes it is necessery that a host of LAN_2 initiates a
> connection to a
> certain computer in LAN_1.
>
> I do this by adding following rule to the gateways' iptables, which also
> works fine:
>
> iptables -t nat -A PREROUTING -j DNAT -i eth1 -d <GATEWAY_ADDR1> --to
> <LAN_1_ADDR>
>
> note: GATEWAY_ADDR1 ... is one of several ip addresses that belong to the
> gateway,
>         LAN_1_ADDR        ... is the address of host that shall be reached
> from LAN_2.
>
> ok now here's my problem:
>
> i thought that i can deny access to LAN_1_ADDR again as soon as the
> connection isnt needed anymore, by simply removing the rule.
>
> this worked if there were no open connections between the hosts, but not if
> the host in LAN_2 already had established one.
>
> here an example:
>
> I logon from LAN_2 to a ftp server in LAN_1 through the gateway via DNAT .
> no problem.
> Now i flush the prerouting chain, remove the rule, whatever.
> DNAT should not be allowed now anymore.
> But the host in LAN_2 still has an open ftp connection and has access to
> the host in LAN_1 until the ftp session is over.
>
> But this must not be possible, i want to avoid it .
>
> I think the host can still be accessed because the connection tracking
> module
> still has the entries of the session stored.
> I tried to "restart" the firewall ( -> flushed _all_ chains, & reset _all_
> rules without dnat the rule) but the connection was still alive.

Only the first packet in a stream will hit the nat-table, so if you remove 
the PREROUTING chain after the connection has already been setup, the 
connection will persist.


> ( if it interests you , new connections to LAN_1_ADDR couldnt be started of
> course ).
>
> Does anyone know how to solve this problem ?

I believe it can only be fixed in the filter module somehow, as all packets 
travel through the filter module. You may insert a rule to the FORWARD chain, 
to block the FTP-traffic from this IP-address; this should take immediate 
effect.

Jan Humme.

Re: Re: unexpected problem with DNAT

[thingstocome]

> I believe it can only be fixed in the filter module somehow, as all
> packets 
> travel through the filter module. You may insert a rule to the FORWARD
> chain, 
> to block the FTP-traffic from this IP-address; this should take immediate 
> effect.
> 
> Jan Humme.
> 

thx for your reply.

hmm if i would attempt to block the packets of the ftp session inside the
FORWARD chain,
the destination address would already have changed to an address of LAN_1 (
because of prerouting).

I think i can't block these packets in the FORWARD chain by checking their
destination address because as you might remember, SNAT ( masquerading) is
also used by LAN_1_ADDR,
so some packets of the masquerading sessions do also have destination
address LAN_1_ADDR when they pass the forward chain ( because NAT is
bidirectional), so they would be blocked as well.

do you know what I mean ? 

i could filter the packets by checking the src address as you suggested,
but this isnt a good idea in my opinion because the src address varies every
time and there can also be several hosts from LAN_2 that had accessed
LAN_1_ADDR at the same time,i would have to manually determinate the addresses of
all these lan_2 hosts every time, and set the filter rules, 
or is there another possibility? 
Am i thinking in the wrong direction ?

It would be great if there were a possibility to simply wipe the entries of
connections
that have been tracked by be conntrack module. 
I think this would be the best solution but i dont know how to do it.  

please tell me if i miss the point somewhere.


-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: Re: unexpected problem with DNAT

[Jan Humme]

On Wednesday 10 July 2002 16:03, thingstocome@gmx.net wrote:
> > I believe it can only be fixed in the filter module somehow, as all
> > packets
> > travel through the filter module. You may insert a rule to the FORWARD
> > chain,
> > to block the FTP-traffic from this IP-address; this should take immediate
> > effect.
> >
> > Jan Humme.
>
> thx for your reply.
>
> hmm if i would attempt to block the packets of the ftp session inside the
> FORWARD chain,
> the destination address would already have changed to an address of LAN_1 (
> because of prerouting).
>
> I think i can't block these packets in the FORWARD chain by checking their
> destination address because as you might remember, SNAT ( masquerading) is
> also used by LAN_1_ADDR,
> so some packets of the masquerading sessions do also have destination
> address LAN_1_ADDR when they pass the forward chain ( because NAT is
> bidirectional), so they would be blocked as well.
>
> do you know what I mean ?

I believe that this is correct.


> i could filter the packets by checking the src address as you suggested,
> but this isnt a good idea in my opinion because the src address varies
> every time and there can also be several hosts from LAN_2 that had accessed
> LAN_1_ADDR at the same time,i would have to manually determinate the
> addresses of all these lan_2 hosts every time, and set the filter rules,
> or is there another possibility?
> Am i thinking in the wrong direction ?
>
> It would be great if there were a possibility to simply wipe the entries of
> connections
> that have been tracked by be conntrack module.
> I think this would be the best solution but i dont know how to do it.
>
> please tell me if i miss the point somewhere.

Well, you can `cat /proc/net/netip_con` to get a list of all connections that 
are being tracked by conntrack, and use a simple script to grep/sed/awk what 
you need to know in order to wipe the necessary entries.

But it is not clear to me what you try to achieve:
=> are you trying to cut the FTP connection in the middle of a transfer?
=> or are you trying to cut the FTP connection after some timeout?
=> and when a host on LAN2 attempts to setup an FTP-connection, do you 
somehow detect this and have iptables jam in a temporary rule?

What I mean is: do you at some point have access to the host's IP-address so 
you can use it to remove the (temporary)? Or perhaps schedule a removal for 
later (eg. using crontab)?

Jan Humme.

Re: Re: unexpected problem with DNAT

[Antony Stone]

On Wednesday 10 July 2002 3:26 pm, Jan Humme wrote:

> On Wednesday 10 July 2002 16:03, thingstocome@gmx.net wrote:
> > > I believe it can only be fixed in the filter module somehow, as all
> > > packets
> > > travel through the filter module. You may insert a rule to the FORWARD
> > > chain,
> > > to block the FTP-traffic from this IP-address; this should take
> > > immediate effect.
> > >
> > > Jan Humme.
> >
> > thx for your reply.
> >
> > hmm if i would attempt to block the packets of the ftp session inside the
> > FORWARD chain,
> > the destination address would already have changed to an address of LAN_1
> > ( because of prerouting).
> >
> > I think i can't block these packets in the FORWARD chain by checking
> > their destination address because as you might remember, SNAT (
> > masquerading) is also used by LAN_1_ADDR,
> > so some packets of the masquerading sessions do also have destination
> > address LAN_1_ADDR when they pass the forward chain ( because NAT is
> > bidirectional), so they would be blocked as well.

The mangle table might be your answer.

Two suggestions:

1. Create a rule in the PREROUTING mangle table (which is processed before 
the nat table, so you can see the original source addesses) and MARK the 
packets which you want to block, and then out a rule in the FORWARD chain to 
DROP the MARKed packets.

That's the 'proper' way to do it - mangle the packets in the mangle table and 
drop them in the filter table, however the quicker, dirtier but more 
efficient way to do it is:

2. Create a rule in the PREROUTING mangle table (which is processed before 
the nat table, so you can see the original source addresses) and DROP the 
packets you want to stop.

 

Antony.

Re: Re: unexpected problem with DNAT

[Jan Humme]

On Wednesday 10 July 2002 16:43, Antony Stone wrote:
> On Wednesday 10 July 2002 3:26 pm, Jan Humme wrote:
> > On Wednesday 10 July 2002 16:03, thingstocome@gmx.net wrote:
> > > > I believe it can only be fixed in the filter module somehow, as all
> > > > packets
> > > > travel through the filter module. You may insert a rule to the
> > > > FORWARD chain,
> > > > to block the FTP-traffic from this IP-address; this should take
> > > > immediate effect.
> > > >
> > > > Jan Humme.
> > >
> > > thx for your reply.
> > >
> > > hmm if i would attempt to block the packets of the ftp session inside
> > > the FORWARD chain,
> > > the destination address would already have changed to an address of
> > > LAN_1 ( because of prerouting).
> > >
> > > I think i can't block these packets in the FORWARD chain by checking
> > > their destination address because as you might remember, SNAT (
> > > masquerading) is also used by LAN_1_ADDR,
> > > so some packets of the masquerading sessions do also have destination
> > > address LAN_1_ADDR when they pass the forward chain ( because NAT is
> > > bidirectional), so they would be blocked as well.
>
> The mangle table might be your answer.
>
> Two suggestions:
>
> 1. Create a rule in the PREROUTING mangle table (which is processed before
> the nat table, so you can see the original source addesses) and MARK the
> packets which you want to block, and then out a rule in the FORWARD chain
> to DROP the MARKed packets.
>
> That's the 'proper' way to do it - mangle the packets in the mangle table
> and drop them in the filter table, however the quicker, dirtier but more
> efficient way to do it is:
>
> 2. Create a rule in the PREROUTING mangle table (which is processed before
> the nat table, so you can see the original source addresses) and DROP the
> packets you want to stop.

I don't get it: the source original addresses are only SNATted *after* the 
FORWARD chain has already been filtered, there is no need to (ab)use the 
mangle chain for this purpose? Or am I misunderstanding something?

So he can directly create one rule in FORWARD chain to drop the packets; but 
his problem seems to be that he doesn't know which IP-addresses he wants to 
block.

Jan Humme.
 

Re: Re: unexpected problem with DNAT

[Antony Stone]

On Wednesday 10 July 2002 4:49 pm, Jan Humme wrote:

> On Wednesday 10 July 2002 16:43, Antony Stone wrote:

> > The mangle table might be your answer.

etc...........

> I don't get it: the source original addresses are only SNATted *after* the
> FORWARD chain has already been filtered, there is no need to (ab)use the
> mangle chain for this purpose? Or am I misunderstanding something?
>
> So he can directly create one rule in FORWARD chain to drop the packets;
> but his problem seems to be that he doesn't know which IP-addresses he
> wants to block.

Ah.   Okay then; in that case I misunderstood the problem and I gave an 
unhelpful solution.   Sorry.

If the original poster doesn't know what addresses s/he wishes to block, then 
I can't think of a netfilter rule which will help :-)

 

Antony.

Re: Re: unexpected problem with DNAT

[Jan Humme]

On Wednesday 10 July 2002 17:55, Antony Stone wrote:
> On Wednesday 10 July 2002 4:49 pm, Jan Humme wrote:
> > On Wednesday 10 July 2002 16:43, Antony Stone wrote:
> > > The mangle table might be your answer.
>
> etc...........
>
> > I don't get it: the source original addresses are only SNATted *after*
> > the FORWARD chain has already been filtered, there is no need to (ab)use
> > the mangle chain for this purpose? Or am I misunderstanding something?
> >
> > So he can directly create one rule in FORWARD chain to drop the packets;
> > but his problem seems to be that he doesn't know which IP-addresses he
> > wants to block.
>
> Ah.   Okay then; in that case I misunderstood the problem and I gave an
> unhelpful solution.   Sorry.
>
> If the original poster doesn't know what addresses s/he wishes to block,
> then I can't think of a netfilter rule which will help :-)

Harty-har-har.........!

But I still don't understand the reason why you would mark (or even DROP) 
packages at the mangle stage, if the same source IP is still available at the 
filter stage?

Please explain, you got me confused.

Jan Humme.

Re: Re: unexpected problem with DNAT

[Antony Stone]

On Wednesday 10 July 2002 5:53 pm, Jan Humme wrote:

> On Wednesday 10 July 2002 17:55, Antony Stone wrote:

> > If the original poster doesn't know what addresses s/he wishes to block,
> > then I can't think of a netfilter rule which will help :-)
>
> Harty-har-har.........!
>
> But I still don't understand the reason why you would mark (or even DROP)
> packages at the mangle stage, if the same source IP is still available at
> the filter stage?

Simple - I got confused by the Subject of the mail thread, and I thought the 
problem was with DNAT, not SNAT.

Of course you are correct that SNAT is done at the *end* of all the 
filtering, therefore any blocking can be done at the FORWARDing stage.

I thought the problem was to block a connection based on its original 
destination address, which had been lost by being DNATted in the PREROUTING 
chain, and therefore it was no longer possible to filter on destination 
address in the FORWARDing chain.

Hope this explains at least part of my confusion, and therefore some of yours 
about my postings ?

 

Antony.

Re: Re: unexpected problem with DNAT

[Jan Humme]

On Wednesday 10 July 2002 19:42, Antony Stone wrote:
> On Wednesday 10 July 2002 5:53 pm, Jan Humme wrote:
> > On Wednesday 10 July 2002 17:55, Antony Stone wrote:
> > > If the original poster doesn't know what addresses s/he wishes to
> > > block, then I can't think of a netfilter rule which will help :-)
> >
> > Harty-har-har.........!
> >
> > But I still don't understand the reason why you would mark (or even DROP)
> > packages at the mangle stage, if the same source IP is still available at
> > the filter stage?
>
> Simple - I got confused by the Subject of the mail thread, and I thought
> the problem was with DNAT, not SNAT.
>
> Of course you are correct that SNAT is done at the *end* of all the
> filtering, therefore any blocking can be done at the FORWARDing stage.
>
> I thought the problem was to block a connection based on its original
> destination address, which had been lost by being DNATted in the PREROUTING
> chain, and therefore it was no longer possible to filter on destination
> address in the FORWARDing chain.
>
> Hope this explains at least part of my confusion, and therefore some of
> yours about my postings ?

It certainly does. Just thought that perhaps there was some clever trick that 
I missed, as I am only starting to get the hang of things.

In any case, we still don't know what the original poster is trying to 
achieve...!

Jan Humme.