Rules not taking effect

Rules not taking effect

[Tib]

I'm using 1.2.6a-5 for debian, using init.d scripts. The problem is that 
when I write a rule, it does not take effect. I have also found that a 
rule I had in place from earlier and I flushed it, still worked even 
though iptables -t nat -L showed nothing. I've been told that the module 
ip_conntrack may have something to do with this, but I cannot rmmod it 
because it's busy and insmod says it's already there. 

Any ideas on what I can do?

<EOL>
Tib

Re: Rules not taking effect

[Antony Stone]

On Friday 18 October 2002 12:27 am, Tib wrote:

> I'm using 1.2.6a-5 for debian, using init.d scripts. The problem is that
> when I write a rule, it does not take effect.

Please explain this ?

> I have also found that a rule I had in place from earlier and I flushed it,
> still worked even though iptables -t nat -L showed nothing.

You mention -t nat specifically.

You should be aware that existing connections which have been NATted bypass 
the explicit rules in the nat table, in order to perform forward and reverse 
NAT transparently, automatically and efficiently.

If your FORWARD chain (I'm assuming this is a routing firewall) contains a 
rule to allow ESTABLISHED packets then further packets in a connection stream 
will continue to pass through the firewall even if you remove the rule/s 
which originally allowed the connection to get set up.

> I've been told that the module ip_conntrack may have something to do with
> this, but I cannot rmmod it because it's busy and insmod says it's already
> there.

What exactly are you trying to do ?   What rules are you trying to remove, or 
what traffic are you trying to block ?

Antony.

-- 

Most people are aware that the Universe is big.

 - Paul Davies, Professor of Theoretical Physics

Re: Rules not taking effect - 2nd try

[Tib]

On Fri, 18 Oct 2002, Antony Stone wrote:

> > I'm using 1.2.6a-5 for debian, using init.d scripts. 
iptables v. 1.2.6a package for debian, init.d scripts for 
start/stop/save_active/save_inactive, etc.

> >The problem is that when I write a rule, it does not take effect.

When I write this rule at the command prompt:

iptables -t nat -A PREROUTING -p tcp -d 216.36.67.63 --dport 40000:40200 
-j DNAT --to-destination 192.168.1.22

it gets added to the table/chain correctly, but does not take effect. IE 
if you telnet to 216.36.67.63 on port 40000, it does not get forwarded to 
192.168.1.22 as it should.

> > I have also found that a rule I had in place from earlier and I flushed it,
> > still worked even though iptables -t nat -L showed nothing.

This rule was already in existance and working fine:

iptables -t nat -A PREROUTING -p tcp -d 216.36.67.63 --dport 4996:5000 
-j DNAT --to-destination 192.168.1.4

But when I flushed it (iptables -t nat -F or iptables -t nat -C PREROUTING 
-D 1), the rule still worked even though iptables -t nat -L showed a blank 
prerouting ruleset.

> You mention -t nat specifically.

Yes, I'm not sure what this comment means though.

> You should be aware that existing connections which have been NATted bypass 
> the explicit rules in the nat table, in order to perform forward and reverse 
> NAT transparently, automatically and efficiently.

But there are were no existing connections on ports 40000:40200, this was
an attempt to forward activity on these ports to a host inside my network
in anticipation of using a program through my firewall.

> If your FORWARD chain (I'm assuming this is a routing firewall) contains a 
> rule to allow ESTABLISHED packets then further packets in a connection stream 
> will continue to pass through the firewall even if you remove the rule/s 
> which originally allowed the connection to get set up.

So as soon as the connection is gone, it would time out and the new rules 
would apply?

> What exactly are you trying to do ?   What rules are you trying to remove, or 
> what traffic are you trying to block ?

Ok - here's my setup:

DSL connection
||
router (which forwards all traffic by default to linux box)
||
linux box (acts as default gateway/masquerade box for internal network. 
||         has web/mail/etc services on it which router forwards traffic 
||         to)
internal network (192.168.1.x - has a host that I am running a program on 
                  that I want incoming connections to reach. it uses ports 
                  40000 to 40200)


Here's the ruleset:

altaica:~# iptables -t filter -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         


altaica:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             216.36.67.63       tcp 
dpts:4996:5000 to:192.168.1.4 

DNAT       tcp  --  anywhere             216.36.67.63       tcp 
dpts:40000:40200 to:192.168.1.22 

DNAT       udp  --  anywhere             216.36.67.63       udp 
dpts:40000:40200 to:192.168.1.22 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         


altaica:~# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


The rule for ports 4996:5000 is to forward dcc connections on irc to my 
desktop machine (this one works, and stayed in effect even when I deleted 
the rule and there were no irc programs running or active connections on 
these ports).

The rules for 40000:40200 are the new rules I added but that don't seem to 
have taken effect. There were no existing connections on these ports since 
there was no service on the linux box on these ports, and no one was 
attempting to connect to them before I setup the rules.


I am trying to find out if, after I write the rules, there is some 
'reload' command I need to feed the system to have it look at iptables 
again and update it's current handling. I had always thought that rules in 
iptables take immediate effect, but someone I know mentioned this having 
something to do with the ip_conntrack module - though I have no idea what 
to do about it.

<EOL>
Tib

ICMP conntrack

[Vincent Lim]

Dear people,

I was wondering why I'm not getting any conntrack entires for icmp
connections?

regards,
Vincent

Re: ICMP conntrack

[Antony Stone]

On Friday 18 October 2002 3:51 am, Vincent Lim wrote:

> Dear people,
>
> I was wondering why I'm not getting any conntrack entires for icmp
> connections?

There is no concept of a "connection" for ICMP.

A single ICMP packet is sent to indicate some situation has occurred.   
There's no reply, there's no follow-up packet, therefore there's no need to 
keeptrack of a "connection" for something which consists of only a single 
packet.

Antony.

-- 

There are only 10 types of people in the world:
those who understand binary notation,
and those who don't.

Re: ICMP conntrack

[Cedric Blancher]

Le ven 18/10/2002 à 10:28, Antony Stone a écrit :
> > I was wondering why I'm not getting any conntrack entires for icmp
> > connections?
> There is no concept of a "connection" for ICMP.

Yes it's true, but for some, you have a request/reply concept.
 
> A single ICMP packet is sent to indicate some situation has occurred.   
> There's no reply, there's no follow-up packet, therefore there's no need to 
> keeptrack of a "connection" for something which consists of only a single 
> packet.

Two cases :

	request/reply : echo, timestamp, address mask and info
		First packet (request) is NEW, others (replies) are
		ESTABLISHED ; entries have a 30s timeout.
		If a unsolicitated reply is received, then INVALID.

	ICMP erros : ICMP payload is a quotation extracted from the IP
		packet that has generated the error. This quotation is
		used to identify the related session in conntrack table.
		If ICMP match an active entry, then it's RELATED. If
		not, it's INVALID.

So, for ICMP requests, you have some kind of conntrack, based on ICMP
sequence number. For ICMP errors, conntrack tries to associate them to
an existing entry.


-- 
Cédric Blancher  <blancher@cartel-securite.fr>
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: ICMP conntrack

[Antony Stone]

On Friday 18 October 2002 10:05 am, Cedric Blancher wrote:

> Le ven 18/10/2002 à 10:28, Antony Stone a écrit :
> > > I was wondering why I'm not getting any conntrack entires for icmp
> > > connections?
> >
> > There is no concept of a "connection" for ICMP.
>
> Yes it's true, but for some, you have a request/reply concept.

Yes, I realised that was the only exception after I posted my reply.

> > A single ICMP packet is sent to indicate some situation has occurred.
> > There's no reply, there's no follow-up packet, therefore there's no need
> > to keeptrack of a "connection" for something which consists of only a
> > single packet.
>
> Two cases :
>
> 	request/reply : echo, timestamp, address mask and info
> 		First packet (request) is NEW, others (replies) are
> 		ESTABLISHED ; entries have a 30s timeout.
> 		If a unsolicitated reply is received, then INVALID.

Indeed.

> 	ICMP erros : ICMP payload is a quotation extracted from the IP
> 		packet that has generated the error. This quotation is
> 		used to identify the related session in conntrack table.
> 		If ICMP match an active entry, then it's RELATED. If
> 		not, it's INVALID.

Although I agree with what you've said here, it's not really relevant to the 
original poster's question, because in these cases you'll still never see an 
ICMP entry in the connection tracking table.   Because the ICMP packets are 
RELATED to the original connection, it's the original packet which you'll see 
in the conntrack table - the ICMP replies simply get through because of their 
relationship to the original packet.

> So, for ICMP requests, you have some kind of conntrack, based on ICMP
> sequence number. For ICMP errors, conntrack tries to associate them to
> an existing entry.

ICMP sequence number ???   What's that ?

Antony.

-- 

If the human brain were so simple that we could understand it,
we'd be so simple that we couldn't.

Re: ICMP conntrack

[Vincent Lim]

Antony Stone wrote:
> 
> On Friday 18 October 2002 10:05 am, Cedric Blancher wrote:
> 
> > Le ven 18/10/2002 à 10:28, Antony Stone a écrit :
> > > > I was wondering why I'm not getting any conntrack entires for icmp
> > > > connections?
> > >
> > > There is no concept of a "connection" for ICMP.
> >
> > Yes it's true, but for some, you have a request/reply concept.
> 
> Yes, I realised that was the only exception after I posted my reply.
> 
> > > A single ICMP packet is sent to indicate some situation has occurred.
> > > There's no reply, there's no follow-up packet, therefore there's no need
> > > to keeptrack of a "connection" for something which consists of only a
> > > single packet.
> >
> > Two cases :
> >
> >       request/reply : echo, timestamp, address mask and info
> >               First packet (request) is NEW, others (replies) are
> >               ESTABLISHED ; entries have a 30s timeout.
> >               If a unsolicitated reply is received, then INVALID.
> 
> Indeed.
> 
> >       ICMP erros : ICMP payload is a quotation extracted from the IP
> >               packet that has generated the error. This quotation is
> >               used to identify the related session in conntrack table.
> >               If ICMP match an active entry, then it's RELATED. If
> >               not, it's INVALID.
> 
> Although I agree with what you've said here, it's not really relevant to the
> original poster's question, because in these cases you'll still never see an
> ICMP entry in the connection tracking table.   Because the ICMP packets are
> RELATED to the original connection, it's the original packet which you'll see
> in the conntrack table - the ICMP replies simply get through because of their
> relationship to the original packet.
> 
> > So, for ICMP requests, you have some kind of conntrack, based on ICMP
> > sequence number. For ICMP errors, conntrack tries to associate them to
> > an existing entry.
> 
> ICMP sequence number ???   What's that ?

Results of a ping to www.ncftpd.com :

64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11055 ttl=44
time=311.029 msec
64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11056 ttl=44
time=308.126 msec
64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11057 ttl=44
time=308.430 msec
64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11058 ttl=44
time=302.321 msec

And the entries in conntrack related to the above is:
icmp     1 29 src=192.168.1.229 dst=209.197.102.38 type=8 code=0
id=59475 src=209.197.102.38 dst=192.168.1.229 type=0 code=0 id=59475
use=1 

However if I try to ping a nearer host, there would be no entry in the
conntrack table at all.

-- 
Vincent Lim
Software Engineer
NESTAC Solution Sdn Bhd
vincent.lim@nestac.com | +(6012) 659-6609

Re: ICMP conntrack

[Antony Stone]

On Friday 18 October 2002 11:07 am, Vincent Lim wrote:

> > > So, for ICMP requests, you have some kind of conntrack, based on ICMP
> > > sequence number. For ICMP errors, conntrack tries to associate them to
> > > an existing entry.
> >
> > ICMP sequence number ???   What's that ?
>
> Results of a ping to www.ncftpd.com :
>
> 64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11055 ttl=44
> time=311.029 msec
> 64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11056 ttl=44
> time=308.126 msec
> 64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11057 ttl=44
> time=308.430 msec
> 64 bytes from ncftpd.com (209.197.102.38): icmp_seq=11058 ttl=44
> time=302.321 msec
>
> And the entries in conntrack related to the above is:
> icmp     1 29 src=192.168.1.229 dst=209.197.102.38 type=8 code=0
> id=59475 src=209.197.102.38 dst=192.168.1.229 type=0 code=0 id=59475
> use=1

Oh - okay - I see what you mean now.   I've just looked up the specs for ICMP 
echo request and indeed there is a sequence number in the "message-code 
specific extra information" field following the first four bytes.

Antony.

-- 

Normal people think "if it ain't broke, don't fix it".
Engineers think "if it ain't broke, it doesn't have enough features yet".

Re: ICMP conntrack

[Cedric Blancher]

Le ven 18/10/2002 à 11:52, Antony Stone a écrit :
> Although I agree with what you've said here, it's not really relevant
> to the  original poster's question, because in these cases you'll
> still never see an ICMP entry in the connection tracking table.  
> Because the ICMP packets are RELATED to the original connection, it's
> the original packet which you'll see in the conntrack table - the ICMP
> replies simply get through because of their
> relationship to the original packet.

True ;)

> > So, for ICMP requests, you have some kind of conntrack, based on ICMP
> > sequence number. For ICMP errors, conntrack tries to associate them to
> > an existing entry.
> ICMP sequence number ???   What's that ?

cbr@elendil:~$ ping thor
PING thor (192.168.10.50): 56 data bytes
64 bytes from 192.168.10.50: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 192.168.10.50: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 192.168.10.50: icmp_seq=2 ttl=255 time=0.2 ms
64 bytes from 192.168.10.50: icmp_seq=3 ttl=255 time=0.3 ms
64 bytes from 192.168.10.50: icmp_seq=4 ttl=255 time=0.3 ms

			     ^^^^^^^^^^
				This

Just spy an ICMP request/reply stuff such as ping with ethereal and look
at sequence number field. It aims to associate received reply to the
good sent request.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: Rules not taking effect - 2nd try

[Antony Stone]

On Friday 18 October 2002 1:32 am, Tib wrote:

> When I write this rule at the command prompt:
>
> iptables -t nat -A PREROUTING -p tcp -d 216.36.67.63 --dport 40000:40200
> -j DNAT --to-destination 192.168.1.22
>
> it gets added to the table/chain correctly, but does not take effect. IE
> if you telnet to 216.36.67.63 on port 40000, it does not get forwarded to
> 192.168.1.22 as it should.

Are you also adding the corresponding FORWARD rule to actually allow the 
packets through the firewall ?

> This rule was already in existance and working fine:
>
> iptables -t nat -A PREROUTING -p tcp -d 216.36.67.63 --dport 4996:5000
> -j DNAT --to-destination 192.168.1.4
>
> But when I flushed it (iptables -t nat -F or iptables -t nat -C PREROUTING
> -D 1), the rule still worked even though iptables -t nat -L showed a blank
> prerouting ruleset.
>
> > You mention -t nat specifically.
>
> Yes, I'm not sure what this comment means though.

I think you need to read some of the documentation available at 
http://www.netfilter.org/documentation in order to learn about filtering, 
address translation, and the differe chains/tables used within netfilter.

> > If your FORWARD chain (I'm assuming this is a routing firewall) contains
> > a rule to allow ESTABLISHED packets then further packets in a connection
> > stream will continue to pass through the firewall even if you remove the
> > rule/s which originally allowed the connection to get set up.
>
> So as soon as the connection is gone, it would time out and the new rules
> would apply?

No, I was assuming you had the standard default DROP policy (you haven't) and 
a FORWARD rule to accept ESTABLISHED,RELATED connections (you haven't).

> > What exactly are you trying to do ?   What rules are you trying to
> > remove, or what traffic are you trying to block ?
>
> Ok - here's my setup:
>
> DSL connection
>
> router (which forwards all traffic by default to linux box)
>
> linux box (acts as default gateway/masquerade box for internal network.
>
> ||         has web/mail/etc services on it which router forwards traffic
> ||         to)
>
> internal network (192.168.1.x - has a host that I am running a program on
>                   that I want incoming connections to reach. it uses ports
>                   40000 to 40200)
>
> Here's the ruleset:

Please can you post your rules again, but this time post the rules 
themselves, not the output from iptables -L   The listing output (a) doesn't 
contain allthe information we need to understand what rules you have, and (b) 
is more confusing (at least for me) because that'snot how I write my rules.

Antony.

-- 

I vote "no" to this proposal to form a committee to investigate whether we 
should or should not hold a ballot on whether to vote yet.

Re: Rules not taking effect - 2nd try

[Tib]

Ok, apologies for self stupidity are owed. I fell prey to the biggest 
blunder of them all: "The Obvious Mistake(tm)". 


DSL connection
|
dsl router (routeable ip)
|
linux box (private ip)
|
internal network (more private ip's)



The dsl IP is the one I was attempting to route, but by the time the 
packet got to the linux box from the router, the routeable ip was already 
mangled to be the linux box ip. So as soon as I put the linux box ip into 
the rule, it worked great and just fine. Only problem is that since it 
goes through double mangling, by the time it gets sent back out to the 
router the dsl router doesn't know where it's supposed to go and loses the 
connection.

So either way, I'm screwed since I've only got one IP. I need a larger 
block in order for this to work right. masquerading just won't cut it. 
Sorry for the headaches everyone.

<EOL>
Tib