No Internet Connection

No Internet Connection

[Giancarlo Boaron]

Ok. So that's my super mega power iptables script I'm
testing for my internet server.

I already put the DHCP rules (my ISP doesn't have a
fixed IP address for the DHCP server. They are always
changing it... don't ask me why) but I didn't test it
yet.

I developed this script using the very good classic
idea: block everything and allow just what I want.

So, this internet server will be a firewall (as soon
as this script works), making NAT (with MASQUERADING).
I also have the SQUID for proxing and caching. 

Some users in my LAN have free pass for everything
while the rest of my users just can connect to the
mail servers (POP and SMTP) and a few users can
connect to ICQ, Messenger, etc (I really don't like
this idea, but I have to do it).

I don't use any authentication method based on user
and password. Instead, I use rules based on the MAC
address for the computers with free pass. (Ok. I know
it isn't a very safe aproach).

So, here goes my script:

INET_IP=`ifconfig eth0 | grep inet | cut -d : -f 2 |
cut -d ' ' -f 2`
INET_IFACE="eth0"

LAN_IP="192.168.0.41"
LAN_IP_RANGE="192.168.0.0/24"
LAN_IFACE="eth1"

LO_IFACE="lo"
LO_IP="127.0.0.1"

Mac1="00:e0:18:3b:af:78"
Mac2="00:50:04:9c:42:23"
Mac3="00:0e:a6:bd:e7:7f"
Mac4="00:c0:df:a5:0c:a5"

IPTABLES="/usr/sbin/iptables"

/sbin/depmod -a
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state
/sbin/modprobe ipt_REJECT
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp

echo "1" > /proc/sys/net/ipv4/ip_forward

$IPTABLES -F
$IPTABLES -X

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

$IPTABLES -N tcp_invalidos

$IPTABLES -A tcp_invalidos -p tcp --tcp-flags SYN,ACK
SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
--state NEW -j LOG \
--log-prefix "Novo nao SYN:"
$IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
--state NEW -j DROP

$IPTABLES -A OUTPUT -p tcp -j tcp_invalidos

$IPTABLES -A OUTPUT -p udp --sport 68 --dport 67 -j
ACCEPT

$IPTABLES -A OUTPUT -p all -m state --state
ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 80 -s $INET_IP -o
$INET_IFACE -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 443 -s $INET_IP -o
$INET_IFACE -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 21 -s $INET_IP -o
$INET_IFACE -j ACCEPT

# ICQ:
$IPTABLES -A OUTPUT -p tcp -d 64.12.163.197 -o
$INET_IFACE -j ACCEPT

$IPTABLES -A INPUT -p tcp -j tcp_invalidos

$IPTABLES -A INPUT -p udp --sport 67 --dport 68 -j
ACCEPT

$IPTABLES -A INPUT -p ALL -m state --state
ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT

# SQUID:
$IPTABLES -A INPUT -i $LAN_IFACE -p tcp --dport 80 -j
ACCEPT

$IPTABLES -A FORWARD -p tcp -j tcp_invalidos

$IPTABLES -A FORWARD -m state --state
ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -m mac --mac-source $Mac1 -j
ACCEPT

$IPTABLES -A FORWARD -m mac --mac-source $Mac2 -j
ACCEPT

$IPTABLES -A FORWARD -m mac --mac-source $Mac3 -j
ACCEPT

$IPTABLES -A FORWARD -m mac --mac-source $Mac4 -j
ACCEPT

$IPTABLES -A FORWARD -p tcp --dport 53 -j ACCEPT
$IPTABLES -A FORWARD -p udp --dport 53 -j ACCEPT

$IPTABLES -A FORWARD -d <my pop server> -p tcp --dport
110 \
-i $LAN_IFACE -j ACCEPT

$IPTABLES -A FORWARD -d <my smtp server> -p tcp
--dport 25 \
-i $LAN_IFACE -j ACCEPT

$IPTABLES -A FORWARD -p tcp --dport 21 -i $LAN_IFACE
-j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 80 -i $LAN_IFACE
-j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 443 -i $LAN_IFACE
-j ACCEPT

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT
--to-source $INET_IP

That's it. Another question: When I configure this
script to run automatically after rebooting the
server, I receive this error message (3 times): "Bad
argument eth0" so the script doesn't work, neither my
Internet access from my LAN and I can't find where is
the error.

However, after rebooting the server and loggin in as
root, I can run the script from command line. It works
and my LAN can access the Internet during that short
time (about 20 minutes. However, I didn't test the
DHCP rules to ckeck if it continues to happen).

Regards
Giancarlo



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: No Internet Connection

[Jason Opperisano]

On Fri, 2004-09-10 at 10:49, Giancarlo Boaron wrote:
> So, here goes my script:
> 
> INET_IP=`ifconfig eth0 | grep inet | cut -d : -f 2 |
> cut -d ' ' -f 2`

maybe this is an ifconfig quirk, but that does not produce an IP address
on my machine here (FC1).  it actually produces nothing.  the working
version here is:

ifconfig eth0 | grep inet | cut -d : -f 2 | cut -d ' ' -f 1

however, might i suggest:

ip -4 -o addr sh eth0 | awk 'NR==1 {print $4}' | cut -d/ -f1

> $IPTABLES -N tcp_invalidos
> 
> $IPTABLES -A tcp_invalidos -p tcp --tcp-flags SYN,ACK
> SYN,ACK \
> -m state --state NEW -j REJECT --reject-with tcp-reset
> $IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
> --state NEW -j LOG \
> --log-prefix "Novo nao SYN:"
> $IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
> --state NEW -j DROP

there's a state called INVALID ("-m state --state INVALID") that could
probably do most of the work for you here...

> $IPTABLES -A OUTPUT -p tcp -j tcp_invalidos
> 
> $IPTABLES -A OUTPUT -p udp --sport 68 --dport 67 -j
> ACCEPT
> 
> $IPTABLES -A OUTPUT -p all -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> 
> $IPTABLES -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
> 
> $IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
> $IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
> 
> $IPTABLES -A OUTPUT -p tcp --dport 80 -s $INET_IP -o
> $INET_IFACE -j ACCEPT
> $IPTABLES -A OUTPUT -p tcp --dport 443 -s $INET_IP -o
> $INET_IFACE -j ACCEPT
> $IPTABLES -A OUTPUT -p tcp --dport 21 -s $INET_IP -o
> $INET_IFACE -j ACCEPT
> 
> # ICQ:
> $IPTABLES -A OUTPUT -p tcp -d 64.12.163.197 -o
> $INET_IFACE -j ACCEPT

are you running an ICQ client on your firewall?  the above rule implies
that you are.  i can't say i recommend this at all.  if your intention
is to allow ICQ *through* the firewall--this rule belongs in FORWARD.

> $IPTABLES -A INPUT -p tcp -j tcp_invalidos
> 
> $IPTABLES -A INPUT -p udp --sport 67 --dport 68 -j
> ACCEPT
> 
> $IPTABLES -A INPUT -p ALL -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> 
> $IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
> $IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
> 
> # SQUID:
> $IPTABLES -A INPUT -i $LAN_IFACE -p tcp --dport 80 -j
> ACCEPT
> 
> $IPTABLES -A FORWARD -p tcp -j tcp_invalidos
> 
> $IPTABLES -A FORWARD -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> 
> $IPTABLES -A FORWARD -m mac --mac-source $Mac1 -j
> ACCEPT
> 
> $IPTABLES -A FORWARD -m mac --mac-source $Mac2 -j
> ACCEPT
> 
> $IPTABLES -A FORWARD -m mac --mac-source $Mac3 -j
> ACCEPT
> 
> $IPTABLES -A FORWARD -m mac --mac-source $Mac4 -j
> ACCEPT
> 
> $IPTABLES -A FORWARD -p tcp --dport 53 -j ACCEPT
> $IPTABLES -A FORWARD -p udp --dport 53 -j ACCEPT
> 
> $IPTABLES -A FORWARD -d <my pop server> -p tcp --dport
> 110 \
> -i $LAN_IFACE -j ACCEPT
> 
> $IPTABLES -A FORWARD -d <my smtp server> -p tcp
> --dport 25 \
> -i $LAN_IFACE -j ACCEPT
> 
> $IPTABLES -A FORWARD -p tcp --dport 21 -i $LAN_IFACE
> -j ACCEPT
> $IPTABLES -A FORWARD -p tcp --dport 80 -i $LAN_IFACE
> -j ACCEPT
> $IPTABLES -A FORWARD -p tcp --dport 443 -i $LAN_IFACE
> -j ACCEPT
> 
> $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT
> --to-source $INET_IP
> 
> That's it. Another question: When I configure this
> script to run automatically after rebooting the
> server, I receive this error message (3 times): "Bad
> argument eth0" so the script doesn't work, neither my
> Internet access from my LAN and I can't find where is
> the error.

it's probably related to the fact that your $INET_IP variable expands to
a text string, not an IP address.

> However, after rebooting the server and loggin in as
> root, I can run the script from command line. It works
> and my LAN can access the Internet during that short
> time (about 20 minutes. However, I didn't test the
> DHCP rules to ckeck if it continues to happen).

are you running your firewall script before your external interface has
an IP address?  if so--this would explain it.  your DHCP client is most
likely being spawned by your /etc/init.d/network script, which usually
kicks off pretty early in rc2.

i cannot explain the "20 minute" phenomenon you refer to.

-j

-- 
Jason Opperisano <opie@817west.com>

Re: No Internet Connection

[Aleksandar Milivojevic]

Giancarlo Boaron wrote:
> INET_IP=`ifconfig eth0 | grep inet | cut -d : -f 2 |
> cut -d ' ' -f 2`

This might not work.  For example, on my home Linux box (FC2) this gives 
the first 2 bytes of link local IPv6 address.  Also, with this approach, 
you must:

a) Make sure this scripts runs *after* dhcpclient configures eth0.

b) Rerun it every time your IP address changes.  There are ISPs out 
there that will let you have same IP address for years, but there are 
some that will force the change of address every day, and there are some 
really bad ones that will force the change every hour.

Anyhow, you don't really need to know this address.  You can use 
something like this on external interface to make sure no spoofing can 
take place (these are private/reserved ranges that should never appear 
on Internet):

-A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
-A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth0 -s 169.254.0.0/16 -j DROP
-A INPUT -i eth0 -s 192.0.2.0/24 -j DROP
-A INPUT -i eth0 -s 204.152.64.0/23 -j DROP
-A INPUT -i eth0 -s 224.0.0.0/3 -j DROP
-A INPUT -i eth0 -s 127.0.0.0/8 -j DROP
-A INPUT -i eth0 -d 192.168.0.0/16 -j DROP
-A INPUT -i eth0 -d 10.0.0.0/8 -j DROP
-A INPUT -i eth0 -d 172.16.0.0/12 -j DROP
-A INPUT -i eth0 -d 169.254.0.0/16 -j DROP
-A INPUT -i eth0 -d 192.0.2.0/24 -j DROP
-A INPUT -i eth0 -d 204.152.64.0/23 -j DROP
-A INPUT -i eth0 -d 224.0.0.0/3 -j DROP
-A INPUT -i eth0 -d 127.0.0.0/8 -j DROP

Repeat this for FORWARD chain.

Now if the packet ends up in INPUT (or FORWARD) chains, and is not 
dropped by these rules, it means it is a valid packet.

> /sbin/depmod -a
> /sbin/modprobe ip_tables
> /sbin/modprobe ip_conntrack
> /sbin/modprobe iptable_filter
> /sbin/modprobe iptable_nat
> /sbin/modprobe ipt_LOG
> /sbin/modprobe ipt_limit
> /sbin/modprobe ipt_state
> /sbin/modprobe ipt_REJECT
> /sbin/modprobe ip_conntrack_ftp
> /sbin/modprobe ip_nat_ftp

Most of these will get automatically loaded.  Leave ip_nat_ftp line, and 
delete all the rest.

> $IPTABLES -N tcp_invalidos
> 
> $IPTABLES -A tcp_invalidos -p tcp --tcp-flags SYN,ACK
> SYN,ACK \
> -m state --state NEW -j REJECT --reject-with tcp-reset
> $IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
> --state NEW -j LOG \
> --log-prefix "Novo nao SYN:"
> $IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
> --state NEW -j DROP

Here's the place where you made an error.  When you reach end of 
"tcp_invalidos" chain, default policy for INPUT/OUTPUT/FORWARD chains 
will be applied (which is DROP).  Which means, all packets will be 
dropped by the firewall.

You need to place this line at the end of "tcp_invalidos":

-A tcp_invalidos -j RETURN

Anyhow, better way of doing this is using (for example):

-A INPUT -i eth1 -p tcp --dport some_port --tcp-flags SYN,ACK,FIN,RST 
SYN -m state --state NEW -j ACCEPT

This ensures that the first packet is really SYN packet with no other 
funny flags set.  This way you don't need tcp_invalidos.

> $IPTABLES -A OUTPUT -p all -m state --state
> ESTABLISHED,RELATED -j ACCEPT

I'd place this one as the very first rule (for all three chains).  Vast 
majority of packets is going to match it, and it doesn't make sense in 
forcing 99% of packets to go through any other rules.

I haven't looked at the rest of you rules...

> That's it. Another question: When I configure this
> script to run automatically after rebooting the
> server, I receive this error message (3 times): "Bad
> argument eth0" so the script doesn't work, neither my
> Internet access from my LAN and I can't find where is
> the error.

Because the ifconfig, grep, cut thingie hasn't returned IP address of 
eth0.  I guess in your case it returned eth0.

> However, after rebooting the server and loggin in as
> root, I can run the script from command line. It works
> and my LAN can access the Internet during that short
> time (about 20 minutes. However, I didn't test the
> DHCP rules to ckeck if it continues to happen).

Strange.  It shouldn't work at all...

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: No Internet Connection

[Jason Opperisano]

On Fri, 2004-09-10 at 12:41, Aleksandar Milivojevic wrote:
> > $IPTABLES -N tcp_invalidos
> > 
> > $IPTABLES -A tcp_invalidos -p tcp --tcp-flags SYN,ACK
> > SYN,ACK \
> > -m state --state NEW -j REJECT --reject-with tcp-reset
> > $IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
> > --state NEW -j LOG \
> > --log-prefix "Novo nao SYN:"
> > $IPTABLES -A tcp_invalidos -p tcp ! --syn -m state
> > --state NEW -j DROP
> 
> Here's the place where you made an error.  When you reach end of 
> "tcp_invalidos" chain, default policy for INPUT/OUTPUT/FORWARD chains 
> will be applied (which is DROP).  Which means, all packets will be 
> dropped by the firewall.

i don't know that i agree with this statement.  when a packet reaches
the end of custom chain "tcp_invalidos" and has not matched any rules in
that chain--it should return to the calling chain where it left off;
i.e.

        iptables -P INPUT DROP
        iptables -A INPUT -j badstuff
        iptables -A INPUT -j goodstuff
        iptables -A INPUT -j LOG
        
a packet not matching any rule in "badstuff" will return to INPUT, and
then jump to "goodstuff"...  if the packet doesn't match any rule in
"goodstuff" it will return to INPUT, get logged, and *then* get dropped,
as it has hit the end of the INPUT chain and not matched any rules. 
only then does the POLICY of the chain get enforced.

-j

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
We don't smoke and we don't chew, and we don't go with girls that do. --
Walter Summers
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

Re: No Internet Connection

[Aleksandar Milivojevic]

Jason Opperisano wrote:
> i don't know that i agree with this statement.  when a packet reaches
> the end of custom chain "tcp_invalidos" and has not matched any rules in
> that chain--it should return to the calling chain where it left off;
> i.e.
> 
>         iptables -P INPUT DROP
>         iptables -A INPUT -j badstuff
>         iptables -A INPUT -j goodstuff
>         iptables -A INPUT -j LOG
>         
> a packet not matching any rule in "badstuff" will return to INPUT, and
> then jump to "goodstuff"...  if the packet doesn't match any rule in
> "goodstuff" it will return to INPUT, get logged, and *then* get dropped,
> as it has hit the end of the INPUT chain and not matched any rules. 
> only then does the POLICY of the chain get enforced.

Hm, interesting...  I vaugly remember (I might be wrong) testing 
something similar a while ago, and I got different results.  Anyhow, 
this seems to be undocumented ("man iptables" doesn't say what happens 
when end of user defined chain is reached).  Could it be that it changed 
from one version to another?

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: No Internet Connection

[Giancarlo Boaron]

Ok Jason. I agree with you. When any packet matches a
specific rule, it returns to the top level rule that
called a down level rule (in this situation, that's
the INPUT chain). And if we have no matches in the
INPUT chain, iptables uses the default policy (DROP).

I tested that DHCP rules and it seems that it's
working. I'm running my script for about 2 hours and
it didn't crash yet. 

So, I think that strange behavior was resolved.

Im going to test that nice ideas when rebooting the
server and another ones suggested in this mail list.

Thank you.
Giancarlo

 --- Jason Opperisano <opie@817west.com> escreveu: 
> On Fri, 2004-09-10 at 12:41, Aleksandar Milivojevic
> wrote:
> > > $IPTABLES -N tcp_invalidos
> > > 
> > > $IPTABLES -A tcp_invalidos -p tcp --tcp-flags
> SYN,ACK
> > > SYN,ACK \
> > > -m state --state NEW -j REJECT --reject-with
> tcp-reset
> > > $IPTABLES -A tcp_invalidos -p tcp ! --syn -m
> state
> > > --state NEW -j LOG \
> > > --log-prefix "Novo nao SYN:"
> > > $IPTABLES -A tcp_invalidos -p tcp ! --syn -m
> state
> > > --state NEW -j DROP
> > 
> > Here's the place where you made an error.  When
> you reach end of 
> > "tcp_invalidos" chain, default policy for
> INPUT/OUTPUT/FORWARD chains 
> > will be applied (which is DROP).  Which means, all
> packets will be 
> > dropped by the firewall.
> 
> i don't know that i agree with this statement.  when
> a packet reaches
> the end of custom chain "tcp_invalidos" and has not
> matched any rules in
> that chain--it should return to the calling chain
> where it left off;
> i.e.
> 
>         iptables -P INPUT DROP
>         iptables -A INPUT -j badstuff
>         iptables -A INPUT -j goodstuff
>         iptables -A INPUT -j LOG
>         
> a packet not matching any rule in "badstuff" will
> return to INPUT, and
> then jump to "goodstuff"...  if the packet doesn't
> match any rule in
> "goodstuff" it will return to INPUT, get logged, and
> *then* get dropped,
> as it has hit the end of the INPUT chain and not
> matched any rules. 
> only then does the POLICY of the chain get enforced.
> 
> -j
> 
>
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
> We don't smoke and we don't chew, and we don't go
> with girls that do. --
> Walter Summers
>
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
> 
> 
>  


	
	
		
_______________________________________________________
Yahoo! Messenger 6.0 - jogos, emoticons sonoros e muita diversão. Instale agora!
http://br.download.yahoo.com/messenger/

Re: No internet connection

[Jason Opperisano]

On Thu, 2004-09-09 at 10:40, Giancarlo Boaron wrote:
> Ok. I made my iptables script and I forgot to handle
> the DHCP protocol. So, my firewall box gets its IP
> address via DHCP. Thats a nice thing to test.

for the sake of the list archives:

  # DHCP server -> client
  iptables -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT

  # DHCP client -> server
  iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT

-j

-- 
Jason Opperisano <opie@817west.com>

Re: No internet connection

[Nick Drage]

On Thu, Sep 09, 2004 at 11:02:18AM -0400, Jason Opperisano wrote:
> On Thu, 2004-09-09 at 10:40, Giancarlo Boaron wrote:
> > Ok. I made my iptables script and I forgot to handle
> > the DHCP protocol. So, my firewall box gets its IP
> > address via DHCP. Thats a nice thing to test.
> 
> for the sake of the list archives:
> 
>   # DHCP server -> client
>   iptables -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
> 
>   # DHCP client -> server
>   iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT

Not wishing to be paranoid, buuuuuuuuutttttttt..... couldn't you
usefully restrict those by source and destination IP?

-- 
mors omnia vincit

Re: No internet connection

[Jason Opperisano]

On Thu, 2004-09-09 at 12:00, Nick Drage wrote:
> > for the sake of the list archives:
> > 
> >   # DHCP server -> client
> >   iptables -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
> > 
> >   # DHCP client -> server
> >   iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT
> 
> Not wishing to be paranoid, buuuuuuuuutttttttt..... couldn't you
> usefully restrict those by source and destination IP?

i dunno.  assuming you know the IP address of the DHCP server in
advance...it could be this:

   iptables -A OUTPUT -p udp -s 0.0.0.0/32 --sport 68 \
     -d 255.255.255.255/32 --dport 67 -j ACCEPT

   iptables -A OUTPUT -p udp --sport 68 \
     -d $DHCP_SRV --dport 67 -j ACCEPT

   iptables -A INPUT -p udp -s $DHCP_SRV --sport 67 \
     --dport 68 -j ACCEPT

with some scripting, you could programatically add in the IP of the FW
to those rules and re-run the iptables script every time the address
changes...

i guess i was trying to show the building blocks of what it takes to
allow a firewall to be a DHCP client...paranoia is left as an exercise
for the reader...  ;-)

-j

-- 
Jason Opperisano <opie@817west.com>

Re: No internet connection

[Aleksandar Milivojevic]

Nick Drage wrote:
> Not wishing to be paranoid, buuuuuuuuutttttttt..... couldn't you
> usefully restrict those by source and destination IP?

Probably, but...  You usually don't know IP address of DHCP server in 
advance (ISP can chage it without prior notice, which will happen each 
time they deem it is time to reorganize their network).  You don't know 
what will be your address before it is assigned to you.

Theoretically, you could modify dhcpclient so that it opens up firewall 
to be more permissive for those two ports when initially getting IP 
address, and than making it more strict when both local and DHCP 
server's addresses are known (and making it more permissive again if 
DHCP server goes south, so that new one could be discovered).

Theretically, your ISP (I guess it's cable, if using DHCP) should have 
been protecting you anyhow.  Otherwise, any wise ass with Windblows or 
Linux box could screw up entire cable segment.  It would be the last 
thing he would do (since it would be trivial to pinpoint him).  But it 
might be considered as fun last thing by the before mentioned wise ass.

On the other hand, you should also assume ISP is brain dead and have 
everything misconfigured (or in better case, not configured at all ;-)

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

RE: No internet connection

[Piszcz, Justin Michael]

Perhaps show us the script?

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Giancarlo
Boaron
Sent: Thursday, September 09, 2004 10:05 AM
To: netfilter@lists.netfilter.org
Subject: No internet connection

Hello.
I'm testing a new iptables script on my server box but
after some minuts that this script is running, the
clients in my LAN have no access to Internet.
I'm using SQUID for proxing and caching.

I think I'm not being very restrictive for my IPTABLES
rules because my clients still have Internet access
after about 20 minuts when the script is running.

What can be wrong? Does my kernel have some limit
about connections? Does it hava someting to do with
the CONTRACK?

Regards.
Giancarlo

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

No internet connection

[Giancarlo Boaron]

Hello.
I'm testing a new iptables script on my server box but
after some minuts that this script is running, the
clients in my LAN have no access to Internet.
I'm using SQUID for proxing and caching.

I think I'm not being very restrictive for my IPTABLES
rules because my clients still have Internet access
after about 20 minuts when the script is running.

What can be wrong? Does my kernel have some limit
about connections? Does it hava someting to do with
the CONTRACK?

Regards.
Giancarlo

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: No internet connection

[Jason Opperisano]

On Thu, 2004-09-09 at 10:04, Giancarlo Boaron wrote:
> Hello.
> I'm testing a new iptables script on my server box but
> after some minuts that this script is running, the
> clients in my LAN have no access to Internet.
> I'm using SQUID for proxing and caching.
> 
> I think I'm not being very restrictive for my IPTABLES
> rules because my clients still have Internet access
> after about 20 minuts when the script is running.
> 
> What can be wrong? Does my kernel have some limit
> about connections? 

of course it does.  i doubt it's the cause of your problem, but if
you're curious:
        grep ip_conntrack /var/log/messages
        
should show you something like:
        ip_conntrack version 2.1 (6142 buckets, 49136 max) - 360 bytes
        per conntrack
        
the number before max (49,136 in this case) is the max number of
conntrack entries for the machine.
        
> Does it hava someting to do with
> the CONTRACK?

i doubt it.  but posting your rules might help:

  iptables -vnL -t mangle && iptables -vnL -t nat && iptables -vnL

i've been batting about zero with my stabs in the dark here
recently--but here goes...

is it possible that you get your external IP via DHCP; and that you're
blocking the DHCP packets between your firewall and the ISP's DHCP
server.  so you get an IP, start up your firewall, and at the first
semaphore period, and either the DHCP server or client decides the other
is no longer there, and your IP gets released?

-j

-- 
Jason Opperisano <opie@817west.com>

Re: No internet connection

[Nick Drage]

On Thu, Sep 09, 2004 at 10:15:51AM -0400, Jason Opperisano wrote:
> On Thu, 2004-09-09 at 10:04, Giancarlo Boaron wrote:
> > Hello.
> > I'm testing a new iptables script on my server box but
> > after some minuts that this script is running, the
> > clients in my LAN have no access to Internet.
> > I'm using SQUID for proxing and caching.

<snip>

> i've been batting about zero with my stabs in the dark here
> recently--but here goes...

Heh, nice way of putting it.

> is it possible that you get your external IP via DHCP; and that you're
> blocking the DHCP packets between your firewall and the ISP's DHCP
> server.  so you get an IP, start up your firewall, and at the first
> semaphore period, and either the DHCP server or client decides the
> other is no longer there, and your IP gets released?

Isn't "some minutes" a rather short time for a DHCP lease to expire
though?

That said, I'm not even going to swing for this one until we get some
more information.

-- 
mors omnia vincit