* Chains policy and rules
@ 2003-07-28 5:47 LiMeiYong
2003-07-28 9:09 ` Chris Wilson
2003-07-28 21:31 ` Arnt Karlsen
0 siblings, 2 replies; 3+ messages in thread
From: LiMeiYong @ 2003-07-28 5:47 UTC (permalink / raw)
To: netfilter, netfilter
I use a PC with 3 NICs.
Their configurations are:
eth0: 152.201.3.179 mask 255.255.0.0
eth1: 152.20.3.181 mask 255.255.0.0
eth2: 192.168.1.181 mask 255.255.255.0
I use two group commands.
1.
#!/bin/sh
echo "Starting iptables rules..."
#Refresh all chains
/sbin/iptables -F
/sbin/iptables -A INPUT -p tcp -d 192.168.1.165 --dport 80 -i eth2 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 192.168.1.165 --dport 22 -i eth2 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.179 --dport ! 80 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.179 --dport ! 22 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.177 --dport ! 80 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.177 --dport ! 22 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.20.3.181 --dport ! 80 -i eth1 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.20.3.181 --dport ! 22 -i eth1 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -j DROP
/sbin/iptables -A INPUT -i eth1 -j DROP
/sbin/iptables -A INPUT -i eth2 -j DROP
2.
/sbin/iptables -F
/sbin/iptables -A INPUT -p tcp -d 192.168.1.165 --dport 80 -i eth2 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 192.168.1.165 --dport 22 -i eth2 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.179 --dport ! 80 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.179 --dport ! 22 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.177 --dport ! 80 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.201.3.177 --dport ! 22 -i eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.20.3.181 --dport ! 80 -i eth1 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -d 152.20.3.181 --dport ! 22 -i eth1 -j ACCEPT
/sbin/iptables -P INPUT DROP
I think both of them shoud do the same things. Yes it does work. But when I use the second group, the connection to 192.168.1.165:80 become very slow. The same thing happend on ssh connection to 192.168.1.165. If I use the first group command, everything is normal! Who can tell me why this happend? What's the difference between droping packets on the chain and droping packets on every ethernet card?
Thanks a million to you who answer this question.
:)
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Chains policy and rules
2003-07-28 5:47 Chains policy and rules LiMeiYong
@ 2003-07-28 9:09 ` Chris Wilson
2003-07-28 21:31 ` Arnt Karlsen
1 sibling, 0 replies; 3+ messages in thread
From: Chris Wilson @ 2003-07-28 9:09 UTC (permalink / raw)
To: LiMeiYong; +Cc: netfilter@lists.netfilter.org
On Mon, 28 Jul 2003, LiMeiYong wrote:
> /sbin/iptables -F
> /sbin/iptables -A INPUT -p tcp -d 192.168.1.165 --dport 80 -i eth2 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 192.168.1.165 --dport 22 -i eth2 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 152.201.3.179 --dport ! 80 -i eth0 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 152.201.3.179 --dport ! 22 -i eth0 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 152.201.3.177 --dport ! 80 -i eth0 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 152.201.3.177 --dport ! 22 -i eth0 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 152.20.3.181 --dport ! 80 -i eth1 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -d 152.20.3.181 --dport ! 22 -i eth1 -j ACCEPT
> /sbin/iptables -P INPUT DROP
>
> I think both of them shoud do the same things. Yes it does work. But when I use the second group, the connection to 192.168.1.165:80 become very slow. The same thing happend on ssh connection to 192.168.1.165. If I use the first group command, everything is normal! Who can tell me why this happend? What's the difference between droping packets on the chain and droping packets on every ethernet card?
> Thanks a million to you who answer this question.
You forgot to allow traffic in from the loopback interface (lo). Without
this, if you have e.g. 127.0.0.1 in your /etc/resolv.conf, it will not
work (you will get a long wait while DNS times out). If you have another
resolver, the lookup will probably succeed when it tries that one, but
after a long delay waiting for the local name server.
Cheers, Chris.
--
___ __ _
/ __// / ,__(_)_ | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Chains policy and rules
2003-07-28 5:47 Chains policy and rules LiMeiYong
2003-07-28 9:09 ` Chris Wilson
@ 2003-07-28 21:31 ` Arnt Karlsen
1 sibling, 0 replies; 3+ messages in thread
From: Arnt Karlsen @ 2003-07-28 21:31 UTC (permalink / raw)
To: LiMeiYong; +Cc: netfilter
On Mon, 28 Jul 2003 13:47:25 +0800,
"LiMeiYong" <jobsli@21cn.com> wrote in message
<87969271865366.03228@send3.inner-21cn.com>:
>
> I use a PC with 3 NICs.
> Their configurations are:
> eth0: 152.201.3.179 mask 255.255.0.0
> eth1: 152.20.3.181 mask 255.255.0.0
..you route traffic for, uh...:
ipcalc -bnmp 152.201.3.179/16
NETMASK=255.255.0.0
PREFIX=16
BROADCAST=152.201.255.255
NETWORK=152.201.0.0
...around 130 thousand boxes on one pc??? Not at all bad! ;-)
..or, are these netmasks too wide? Searching 130 000 takes
a _while_, even if everything else works ok. Depending on
your network layout, reconsider your sub net strategy,
chances are _fat_ a few thousand subnets with an handful
of hosts in each, will prove faster. Good Luck. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-07-28 21:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-28 5:47 Chains policy and rules LiMeiYong
2003-07-28 9:09 ` Chris Wilson
2003-07-28 21:31 ` Arnt Karlsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox