allow range syntax - perplexed

allow range syntax - perplexed

[Jonathan Villa]

To my understanding the following will allow any address in the x.x.x.0
block access

$IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24  -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT

It of course is not working...

my temporary solution : looping through 1-254

not very nice when I need to show someone the current rules.

-confused

Re: allow range syntax - perplexed

[Cedric Blancher]

Le mar 15/06/2004 à 19:00, Jonathan Villa a écrit :
> my temporary solution : looping through 1-254

As someone pointed out yesterday, you can use iprange match from POM :

http://www.netfilter.org/patch-o-matic/pom-base.html#pom-base-iprange

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: allow range syntax - perplexed

[Jonathan Villa]

> Le mar 15/06/2004 à 19:00, Jonathan Villa a écrit :
>> my temporary solution : looping through 1-254
>
> As someone pointed out yesterday, you can use iprange match from POM :
>
> http://www.netfilter.org/patch-o-matic/pom-base.html#pom-base-iprange
>

thanks, I saw that post.  However I just started working with iptables and
have never patched it.  I've just updated when new RPMS became available. 
I guess I'll look into it.

Re: allow range syntax - perplexed

[Jonathan Villa]

> Le mar 15/06/2004 à 19:00, Jonathan Villa a écrit :
>> my temporary solution : looping through 1-254
>
> As someone pointed out yesterday, you can use iprange match from POM :
>
> http://www.netfilter.org/patch-o-matic/pom-base.html#pom-base-iprange
>
> --


I've just read that using POM is not considered safe by the dev team. 
http://www.lowth.com/howto/add-iptables-modules.php

This is for a running system that needs to stay up right now. Any other
options?

Re: allow range syntax - perplexed

[John A. Sullivan III]

On Tue, 2004-06-15 at 13:00, Jonathan Villa wrote:
> To my understanding the following will allow any address in the x.x.x.0
> block access
> 
> $IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24  -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT
> 
> It of course is not working...
> 
> my temporary solution : looping through 1-254
> 
> not very nice when I need to show someone the current rules.
> 
> -confused
I'm not doing exactly what you are doing but I do use full subnets for
both source and destination and it works fine for me.  What do you see
that makes you believe it is not working? - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Re: allow range syntax - perplexed

[Jonathan Villa]

> I'm not doing exactly what you are doing but I do use full subnets for
> both source and destination and it works fine for me.  What do you see
> that makes you believe it is not working? - John
> --
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> ---
> If you are interested in helping to develop a GPL enterprise class
> VPN/Firewall/Security device management console, please visit
> http://iscs.sourceforge.net
>
>

Access is denied.

I have more information now.

Here is the background:
A machine running MySQL is to be locked down for access only to a select
group of people working from home and people at the office, hence the
xx.xx.xx.0

I've noticed that the script works fine for anyone who is not on the
network but for those who are, well the rules block access to them all the
time.

I have something similar to the following

ALLOWIPS="array of ip addresses"

for ip in $ALLOWIPS;
do
$IPTABLES -A INPUT -p tcp --dport 3306 -s $ip -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT
done

then I had the rules from my original post

$IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT

the ips in the loop are fine, but then ips on the same network were being
blocked regardless of my rules.  That is why I thought that it was the
syntax...

I have added 5 ips which are on the same network as the server to the
array ALLOWIPS and they get denied access while the other ips are granted
access.

so then I tried taking them out of the loop and doing them individually,
still no access.

Could it be because they are on the block?  Do I need to specify that the
interface is -i eth0 or something instead of specifying -s ip

example

use:


$IPTABLES -A INPUT -p tcp --dport 3306 -i eth0  -j ACCEPT

vs


$IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT


but then my question is, I only have one nic, so won't everything that is
not from lo come from eth0?

-very confused

Re: allow range syntax - perplexed

[Antony Stone]

On Tuesday 15 June 2004 6:00 pm, Jonathan Villa wrote:

> To my understanding the following will allow any address in the x.x.x.0
> block access
>
> $IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24  -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT

I agree - the above rules should allow any IP within the xxx.xxx.xx.0/24 Class 
C range access the firewall on port 22, 80 or 3306.

> It of course is not working...

Huh?   Why "of course"?   Come to that, why isn't it working?   I use that 
sort of netmask notation all the time...

> my temporary solution : looping through 1-254

Ugh!

Show us the rest of your INPUT and OUTPUT ruleset, and tell us how you are 
testing the system (and where from).

The output from "iptables -L -nvx" would be useful, as it shows us the rules 
in the correct order, which interfaces they apply to, and the packet / byte 
counts so we can see how many times particular rules have been matched.

Feel free to munge IP addresses if you want to hide things from the list 
archives :)

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: allow range syntax - perplexed

[Antony Stone]

On Tuesday 15 June 2004 7:41 pm, Jonathan Villa wrote:

> I have more information now.
>
> Here is the background:
> A machine running MySQL is to be locked down for access only to a select
> group of people working from home and people at the office, hence the
> xx.xx.xx.0

Is the MySQL machine on the same subnet as the office people trying to access 
it, or is there a firewall in between, with the MySQL on a DMZ network?

If it's the latter, are you sure your office machines aren't being masqueraded 
in some way by the firewall when they try to access the MySQL server, so that 
it sees an address on the firewall instead of the real address of the 
clients?

> I've noticed that the script works fine for anyone who is not on the
> network but for those who are, well the rules block access to them all the
> time.

I suggest you add a LOGging rule at the bottom of the INPUT chain and see what 
source address the packets which are not being ACCEPTed are coming from.

Regards,

Antony.

-- 
This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: allow range syntax - perplexed

[John A. Sullivan III]

On Tue, 2004-06-15 at 14:41, Jonathan Villa wrote:
> > I'm not doing exactly what you are doing but I do use full subnets for
> > both source and destination and it works fine for me.  What do you see
> > that makes you believe it is not working? - John
> > --
> > John A. Sullivan III
> > Chief Technology Officer
> > Nexus Management
> > +1 207-985-7880
> > john.sullivan@nexusmgmt.com
> > ---
> > If you are interested in helping to develop a GPL enterprise class
> > VPN/Firewall/Security device management console, please visit
> > http://iscs.sourceforge.net
> >
> >
> 
> Access is denied.
> 
> I have more information now.
> 
> Here is the background:
> A machine running MySQL is to be locked down for access only to a select
> group of people working from home and people at the office, hence the
> xx.xx.xx.0
> 
> I've noticed that the script works fine for anyone who is not on the
> network but for those who are, well the rules block access to them all the
> time.
> 
> I have something similar to the following
> 
> ALLOWIPS="array of ip addresses"
> 
> for ip in $ALLOWIPS;
> do
> $IPTABLES -A INPUT -p tcp --dport 3306 -s $ip -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT
> done
> 
> then I had the rules from my original post
> 
> $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT
> 
> the ips in the loop are fine, but then ips on the same network were being
> blocked regardless of my rules.  That is why I thought that it was the
> syntax...
> 
> I have added 5 ips which are on the same network as the server to the
> array ALLOWIPS and they get denied access while the other ips are granted
> access.
> 
> so then I tried taking them out of the loop and doing them individually,
> still no access.
> 
> Could it be because they are on the block?  Do I need to specify that the
> interface is -i eth0 or something instead of specifying -s ip
> 
> example
> 
> use:
> 
> 
> $IPTABLES -A INPUT -p tcp --dport 3306 -i eth0  -j ACCEPT
> 
> vs
> 
> 
> $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
> 
> 
> but then my question is, I only have one nic, so won't everything that is
> not from lo come from eth0?
> 
> -very confused
Hmmm . . . that is very confusing.  It should work which makes me think
something else is going on.  I would suggest it is time to do a little
tracing to find out where the problem really is.

I would suggest that the first order of business be ensure that the
packets are making it to the MySQL server.  One could enable all traffic
and see if you are still denied (if so, a good sign that the packets
never make it there in the first place) or, if that is impractical or
you really want to be sure, put a protocol analyzer on the line (e.g.,
http://www.ethereal.com).  If the server is on a switch, you can either
insert a hub, use port mirroring or use ettercap
(http://ettercap.sourceforge.net) to insert yourself into the packet
stream.  If you do not see the packets arriving, we know the problem is
somewhere else in the network.

If the packets arrive at the MySQL server, then I would start placing
log rules at various points in the iptables rules set to see where the
packets are dropped.  If they are not dropped before the ACCEPT rule,
then see if they are still in the chain after the ACCEPT rule (in which
case something is wrong with the match portion of the rule).  If not,
they have been ACCEPTED and are either being DROPped or mangled in
another POSTROUTING chain or, more likely, there is an application layer
problem.

Regarding interface versus subnet, it depends on which you fear most!
The interface allows you to add new subnets and they will all be allowed
based upon port regardless of IP.  If that kind of free access scares
you, then restrict it to specific addresses and subnets (which seems
like it is what you want to do anyway).  The downside there is that you
must change the rules for any subnets or addresses you later add.  If
that kind of maintenance scares you, go back to allowing everything from
the allowed ports on the interface.

Hope this helps - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Re: allow range syntax - perplexed

[Jonathan Villa]

[-- Attachment #1: Type: text/plain, Size: 11654 bytes --]




> On Tuesday 15 June 2004 6:00 pm, Jonathan Villa wrote:
>
>> To my understanding the following will allow any address in the x.x.x.0
>> block access
>>
>> $IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24  -j ACCEPT
>> $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
>> $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT
>
> I agree - the above rules should allow any IP within the xxx.xxx.xx.0/24
> Class
> C range access the firewall on port 22, 80 or 3306.
>
>> It of course is not working...
>
> Huh?   Why "of course"?   Come to that, why isn't it working?   I use that
> sort of netmask notation all the time...

I didn't meant "of course" in a bad way, I meant it in reference to my bad
luck.


>> my temporary solution : looping through 1-254
>
> Ugh!

yes, very much.


> Show us the rest of your INPUT and OUTPUT ruleset, and tell us how you are
> testing the system (and where from).
>
> The output from "iptables -L -nvx" would be useful, as it shows us the
> rules
> in the correct order, which interfaces they apply to, and the packet /
> byte
> counts so we can see how many times particular rules have been matched.
>
> Feel free to munge IP addresses if you want to hide things from the list
> archives :)
>


here is the output for iptables -L -nvx. I've also attached a txt file in
case you want to see a cleaner output

One thing to keep in mind, since we are trying to use the machine, I had
to open up some ports to everyone :( until the issue is resolved.

Chain INPUT (policy ACCEPT 2403 packets, 206290 bytes)
    pkts      bytes target     prot opt in     out     source             
 destination
       0        0 ACCEPT     icmp --  eth0   *       0.0.0.0/0           
0.0.0.0/0           state ESTABLISHED
   23171  1256484 ACCEPT     tcp  --  eth0   *       0.0.0.0/0           
0.0.0.0/0           state ESTABLISHED
       1      137 ACCEPT     udp  --  eth0   *       0.0.0.0/0           
0.0.0.0/0           state ESTABLISHED
       0        0 ACCEPT     tcp  --  *      *       127.0.0.1           
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       127.0.0.1           
0.0.0.0/0           tcp dpt:3306
      28     1512 ACCEPT     tcp  --  *      *       127.0.0.1           
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx         
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx         
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx         
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xxx        
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xxx        
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xxx        
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx        
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx       
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xx       
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xx       
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx      
0.0.0.0/0           tcp dpt:80
      99     4512 ACCEPT     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:3306
       1       52 ACCEPT     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.x.xxx.xxx        
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx       
0.0.0.0/0           tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xxx.x        
0.0.0.0/0           tcp dpt:22
    6442   564926 LOG        all  --  !lo    *       0.0.0.0/0           
0.0.0.0/0           limit: avg 3/sec burst 5 LOG flags 0 level 4
    8334   748621 DROP       all  --  !lo    *       0.0.0.0/0           
0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source             
 destination
       0        0 RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0  
         0.0.0.0/0

Chain OUTPUT (policy ACCEPT 69219 packets, 67312095 bytes)
    pkts      bytes target     prot opt in     out     source             
 destination

Chain RH-Firewall-1-INPUT (1 references)
    pkts      bytes target     prot opt in     out     source             
 destination
       0        0 ACCEPT     all  --  lo     *       0.0.0.0/0           
0.0.0.0/0
       0        0 ACCEPT     icmp --  *      *       0.0.0.0/0           
0.0.0.0/0           icmp type 255
       0        0 ACCEPT     esp  --  *      *       0.0.0.0/0           
0.0.0.0/0
       0        0 ACCEPT     ah   --  *      *       0.0.0.0/0           
0.0.0.0/0
       0        0 ACCEPT     all  --  *      *       0.0.0.0/0           
0.0.0.0/0           state RELATED,ESTABLISHED
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           state NEW tcp dpt:3306
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           state NEW tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0           state NEW tcp dpt:80
       0        0 REJECT     all  --  *      *       0.0.0.0/0           
0.0.0.0/0           reject-with icmp-host-prohibited


here's my script

#!/bin/bash
#
# Allow only access to MySQL, HTTP, and SSH
#
IPTABLES=/sbin/iptables

#flush existing rules
$IPTABLES -F INPUT

#This allows all data that has been sent out for the computer running the
firewall
# to come back
#(for all of ICMP/TCP/UDP).
#For example, if a ping request is made it will allow the reply back
$IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED -i eth0 -p icmp
$IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED -i eth0 -p tcp
$IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED -i eth0 -p udp

#list of ips allowed to access the server
ALLOWIPS="127.0.0.1 etc... etc..."

for ip in $ALLOWIPS;
do
$IPTABLES -A INPUT -p tcp --dport 22 -s $ip  -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 3306 -s $ip -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT
done

#$IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24  -j ACCEPT
#$IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24  -j ACCEPT
#$IPTABLES -A INPUT -p tcp --dport 80 -s xxx.XXX.XX.0/24 -j ACCEPT


#do not modify.  Allows JV access from office, home, and from remote
server for the weekends JVIPS="more ips"

for jvip in $JVIPS;
do
$IPTABLES -A INPUT -p tcp --dport 22 -s $jvip -j ACCEPT
done

#Drop and log all other data
#The logging is set so if more than 5 packets are dropped in
#three seconds they will be ignored. This helps to prevent a DOS attack
#Crashing the computer the firewall is running on
$IPTABLES -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG

#drop anything else that does not come from the localhost interface
$IPTABLES -A INPUT -i ! lo -j DROP

#save rules
/etc/init.d/iptables save



[-- Attachment #2: out.txt --]
[-- Type: text/plain, Size: 8426 bytes --]

Chain INPUT (policy ACCEPT 2403 packets, 206290 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           state ESTABLISHED 
   23171  1256484 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           state ESTABLISHED 
       1      137 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           state ESTABLISHED 
       0        0 ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpt:3306 
      28     1512 ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx          0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx          0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx          0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xxx         0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xxx         0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xx.xxx         0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xx         0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xx.xxx.xxx        0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xx        0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xx        0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       xxx.xxx.xx.xxx       0.0.0.0/0           tcp dpt:80 
      99     4512 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 
       1       52 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.x.xxx.xxx         0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xx.xxx        0.0.0.0/0           tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       xx.xxx.xxx.x         0.0.0.0/0           tcp dpt:22 
    6442   564926 LOG        all  --  !lo    *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/sec burst 5 LOG flags 0 level 4 
    8334   748621 DROP       all  --  !lo    *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 69219 packets, 67312095 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain RH-Firewall-1-INPUT (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 255 
       0        0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     ah   --  *      *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:3306 
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80 
       0        0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Re: allow range syntax - perplexed

[Jonathan Villa]

> On Tuesday 15 June 2004 7:41 pm, Jonathan Villa wrote:
>
>> I have more information now.
>>
>> Here is the background:
>> A machine running MySQL is to be locked down for access only to a select
>> group of people working from home and people at the office, hence the
>> xx.xx.xx.0
>
> Is the MySQL machine on the same subnet as the office people trying to
> access
> it, or is there a firewall in between, with the MySQL on a DMZ network?

Sad to say, but there is no firewall.  Machines are open to the world,
hence the xxx.xxx.xxx.xxx everywhere.


> If it's the latter, are you sure your office machines aren't being
> masqueraded
> in some way by the firewall when they try to access the MySQL server, so
> that
> it sees an address on the firewall instead of the real address of the
> clients?
>
>> I've noticed that the script works fine for anyone who is not on the
>> network but for those who are, well the rules block access to them all
>> the
>> time.
>
> I suggest you add a LOGging rule at the bottom of the INPUT chain and see
> what
> source address the packets which are not being ACCEPTed are coming from.

Good point.  Since I am fairly new to iptables, I usually carry my book
with me, unfortunately, I don't have it today.  But I will implement lots
of logging to help once I figure out how to :)


> Regards,
>
> Antony.
>
>

Re: allow range syntax - perplexed

[Jonathan Villa]

> Hmmm . . . that is very confusing.  It should work which makes me think
> something else is going on.  I would suggest it is time to do a little
> tracing to find out where the problem really is.
>
> I would suggest that the first order of business be ensure that the
> packets are making it to the MySQL server.  One could enable all traffic
> and see if you are still denied (if so, a good sign that the packets
> never make it there in the first place) or, if that is impractical or
> you really want to be sure, put a protocol analyzer on the line (e.g.,
> http://www.ethereal.com).  If the server is on a switch, you can either
> insert a hub, use port mirroring or use ettercap
> (http://ettercap.sourceforge.net) to insert yourself into the packet
> stream.  If you do not see the packets arriving, we know the problem is
> somewhere else in the network.
>
> If the packets arrive at the MySQL server, then I would start placing
> log rules at various points in the iptables rules set to see where the
> packets are dropped.  If they are not dropped before the ACCEPT rule,
> then see if they are still in the chain after the ACCEPT rule (in which
> case something is wrong with the match portion of the rule).  If not,
> they have been ACCEPTED and are either being DROPped or mangled in
> another POSTROUTING chain or, more likely, there is an application layer
> problem.
>
> Regarding interface versus subnet, it depends on which you fear most!
> The interface allows you to add new subnets and they will all be allowed
> based upon port regardless of IP.  If that kind of free access scares
> you, then restrict it to specific addresses and subnets (which seems
> like it is what you want to do anyway).  The downside there is that you
> must change the rules for any subnets or addresses you later add.  If
> that kind of maintenance scares you, go back to allowing everything from
> the allowed ports on the interface.

Packets are making it to the server just fine for ip addresses not on the
same network.  For example, I am 3 hours away and can access the machine
via port 80, 3306, and 22.  When I create the rules for ips on the same
network, they can't even access port 80 for phpMyAdmin.  But once I remove
the ip check and allow access for the whole world, they are fine.

Re: allow range syntax - perplexed

[Antony Stone]

On Tuesday 15 June 2004 8:24 pm, Jonathan Villa wrote:

> > The output from "iptables -L -nvx" would be useful, as it shows us the
> > rules
> > in the correct order, which interfaces they apply to, and the packet /
> > byte
> > counts so we can see how many times particular rules have been matched.
>
> here is the output for iptables -L -nvx. I've also attached a txt file in
> case you want to see a cleaner output

Nice.   The .txt file was much easier to read :)

The first thing I notice about the ruleset you have posted is that none of the 
rules which included your network range matched any packets at all.

Therefore that doesn't tell us much about what source address/es the packets 
you are having problems with are coming from.

Maybe the timing was just unfortunate, but I can't see any TCP port 3306 
packets at all.   Therefore I think a LOG rule would be a good idea, to try 
and track down where the packets are coming from, which your 
carefully-crafted -s xxx.xxx.xx.0/24 rules aren't apparently matching.

Try something like the following:

iptables -A INPUT -p tcp --dport 3306 -j LOG

The -A will ensure that the rule comes after all your other rules (which are 
supposed to ACCEPT the packets one way or another).   However, I notice you 
have a default ACCEPT policy (ugh) and a final rule which DROPs all 
non-loopback packets.   I suggest you change this to a default DROP policy 
and a final rule which ACCEPTs all the loopback packets.   Then the rule 
above will become the final rule in your chain, guaranteeing that you LOG any 
packets destined for MySQL just before they get (unfortunately) DROPped.

Regards,

Antony.

-- 
There are two possible outcomes:

 If the result confirms the hypothesis, then you've made a measurement.
 If the result is contrary to the hypothesis, then you've made a discovery.

 - Enrico Fermi

                                                     Please reply to the list;
                                                           please don't CC me.

Re: allow range syntax - perplexed

[Jonathan Villa]

> On Tuesday 15 June 2004 8:24 pm, Jonathan Villa wrote:
>
>> > The output from "iptables -L -nvx" would be useful, as it shows us the
>> > rules
>> > in the correct order, which interfaces they apply to, and the packet /
>> > byte
>> > counts so we can see how many times particular rules have been
>> matched.
>>
>> here is the output for iptables -L -nvx. I've also attached a txt file
>> in
>> case you want to see a cleaner output
>
> Nice.   The .txt file was much easier to read :)
>
> The first thing I notice about the ruleset you have posted is that none of
> the
> rules which included your network range matched any packets at all.

My serious bad!!!!  I am so overworked that I was staring at the ip
addresses and never realized that I was using xx1. rather than xx3 which
is the correct one.  It now works as expected.

>
> Therefore that doesn't tell us much about what source address/es the
> packets
> you are having problems with are coming from.
>
> Maybe the timing was just unfortunate, but I can't see any TCP port 3306
> packets at all.   Therefore I think a LOG rule would be a good idea, to
> try
> and track down where the packets are coming from, which your
> carefully-crafted -s xxx.xxx.xx.0/24 rules aren't apparently matching.
>
> Try something like the following:
>
> iptables -A INPUT -p tcp --dport 3306 -j LOG
thanks, this will help

>
> The -A will ensure that the rule comes after all your other rules (which
> are
> supposed to ACCEPT the packets one way or another).   However, I notice
> you
> have a default ACCEPT policy (ugh)

I agree.  When I planned the rules, it was set to DROP however with the
"issue" I was having, I changed it.

and a final rule which DROPs all
> non-loopback packets.   I suggest you change this to a default DROP policy
> and a final rule which ACCEPTs all the loopback packets.   Then the rule
> above will become the final rule in your chain, guaranteeing that you LOG
> any
> packets destined for MySQL just before they get (unfortunately) DROPped.
>

One quick question regarding logging.  Where does it get logged to?  I
check  /var/log/messages and see lots of traffic being logged at a rapid
rate.  I've read that syslog takes care logging, but I would prefer to
have a separate log.

Again, my original issue was a silly mistake.  Sorry for wasting anyone's
time.

blocking all traffic in port 137/137

[david]

Dear all,
When i look at "IPTRAF", i see lot of broadcast traffic that using port 137
and 138, how to make rules that can block all traffic in port 137 and 138, i
already try to use this rules but its no works...

iptables -A INPUT -p tcp --dport 137 DROP
iptables -A OUTPUT -p tcp --dport 137 DROP
iptables -A INPUT -p udp --dport 137 DROP
iptables -A OUTPUT -p udp --dport 137 DROP
iptables -A INPUT -p tcp --dport 138 DROP
iptables -A OUTPUT -p tcp --dport 138 DROP
iptables -A INPUT -p udp --dport 138 DROP
iptables -A OUTPUT -p udp --dport 138 DROP
iptables -A INPUT -p icmp DROP

Thank's
David Kandou

Re: blocking all traffic in port 137/137

[Antony Stone]

On Wednesday 16 June 2004 9:47 am, david wrote:

> Dear all,
> When i look at "IPTRAF", i see lot of broadcast traffic that using port 137
> and 138,

You must have Windows machines on your network, then - that's how Microsoft 
networking works - using broadcasts on the local subnet.

> how to make rules that can block all traffic in port 137 and 138,

Why bother?   It's broadcast traffic - it's not going anywhere (through a 
router), and if your firewall doesn't listen on those ports, nothing's going 
to happen anyway.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.

Re: blocking all traffic in port 137/137

[Frank Gruellich]

* david <david@suarapembaruan.co.id> 16. Jun 04:
> Dear all,

Hi,

> When i look at "IPTRAF", i see lot of broadcast traffic that using port 137
> and 138, how to make rules that can block all traffic in port 137 and 138, i
> already try to use this rules but its no works...

Additional to Antonys statement the OUTPUT-rules should be even more
useless.  Are you runnig netbios at a linux-box?

> iptables -A INPUT -p tcp --dport 137 DROP
> iptables -A INPUT -p udp --dport 137 DROP
> iptables -A INPUT -p tcp --dport 138 DROP
> iptables -A INPUT -p udp --dport 138 DROP
> iptables -A INPUT -p icmp DROP

And ICMP is _not_ bad.  Don't DROP it.

HTH,
 regards, Frank.
-- 
Sigmentation fault

Relay to DNS Server ?

[Akao]

Hello
I have set up a netfilter box as a gateway.
The network lookis like this:

subnet ---- eth1 - Netfilter box - eth0 --- modem/router --- FAI

The forwarding/masquerading is working fine, subnet boxes can ping 
external ip like.

But they can' t resolve domain names, because there isn' t any DNS 
server in the subnet.
I d like to use DNS Servers of the ISP, or another DNS Server I would 
set up OUTSIDE the subnet.
The netfilter box has the ISP DNS servers in resolv.conf and its gateway 
is the router.It  resolves domains names without problems.

Is it possible to use netfilter rules to "relay" clients DNS requests ?
Sorry but I m new to netfilter.

Thanks in advance.
Regards

Axel

Re: Relay to DNS Server ?

[Patrick Leslie Polzer]

On Wed, 16 Jun 2004 15:31:37 +0200
Akao <technique@akao.fr> wrote:

> Is it possible to use netfilter rules to "relay" clients DNS requests ?
Masquerading does that, but you must allow packets to port 53 tcp/udp to
pass through to your ISP's DNS servers and their related packets back.

Leslie

Re: Relay to DNS Server ?

[Antony Stone]

On Wednesday 16 June 2004 2:53 pm, Patrick Leslie Polzer wrote:

> On Wed, 16 Jun 2004 15:31:37 +0200
>
> Akao <technique@akao.fr> wrote:
> > Is it possible to use netfilter rules to "relay" clients DNS requests ?
>
> Masquerading does that, but you must allow packets to port 53 tcp/udp to
> pass through to your ISP's DNS servers and their related packets back.

This is a completely correct and accurate answer to your question, however I 
think you would get much better performance for very little effort if you set 
up a simple caching-only name server somewhere on your network (possibly even 
on the firewall itself, but don't tell anyone I suggested that :)

Regards,

Antony.

-- 
"640 kilobytes (of RAM) should be enough for anybody."

 - Bill Gates

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Relay to DNS Server ?

[Mark Anacker]

Antony Stone wrote:
> On Wednesday 16 June 2004 2:53 pm, Patrick Leslie Polzer wrote:
> 
> 
>>On Wed, 16 Jun 2004 15:31:37 +0200
>>
>>Akao <technique@akao.fr> wrote:
>>
>>>Is it possible to use netfilter rules to "relay" clients DNS requests ?
>>
>>Masquerading does that, but you must allow packets to port 53 tcp/udp to
>>pass through to your ISP's DNS servers and their related packets back.
> 
> 
> This is a completely correct and accurate answer to your question, however I 
> think you would get much better performance for very little effort if you set 
> up a simple caching-only name server somewhere on your network (possibly even 
> on the firewall itself, but don't tell anyone I suggested that :)
> 
> Regards,
> 
> Antony.
> 

You might want to run a DNS cache like dnsmasq on the firewall box, then 
use a REDIRECT or DNAT rule to grab client's requests and force them 
into the cache.  That way, the client's don't have to change their DNS 
server list, and you get the benefits of caching.

-- 
Mark Anacker
Chameleon Technology, Inc.

Re: Relay to DNS Server ?

[Akao]

Mark Anacker wrote:

> Antony Stone wrote:
>
>> On Wednesday 16 June 2004 2:53 pm, Patrick Leslie Polzer wrote:
>>
>>
>>> On Wed, 16 Jun 2004 15:31:37 +0200
>>>
>>> Akao <technique@akao.fr> wrote:
>>>
>>>> Is it possible to use netfilter rules to "relay" clients DNS 
>>>> requests ?
>>>
>>>
>>> Masquerading does that, but you must allow packets to port 53 
>>> tcp/udp to
>>> pass through to your ISP's DNS servers and their related packets back.
>>
>>
>>
>> This is a completely correct and accurate answer to your question, 
>> however I think you would get much better performance for very little 
>> effort if you set up a simple caching-only name server somewhere on 
>> your network (possibly even on the firewall itself, but don't tell 
>> anyone I suggested that :)
>>
>> Regards,
>>
>> Antony.
>>
>
> You might want to run a DNS cache like dnsmasq on the firewall box, 
> then use a REDIRECT or DNAT rule to grab client's requests and force 
> them into the cache.  That way, the client's don't have to change 
> their DNS server list, and you get the benefits of caching.
>
Ok, thanks for your answers.
 I managed to complete clients DNS requests with masquerading. I will 
look for a dns cache as you adviced me.

Thanks again for your answers.

Axel