Several Questions/Comments

Thu, 31 Jan 2002 17:47:46 +0100

Hey there,

first of all please bear with me. I've read the HOWTO's totally and the FAQ 
partially. Unfortunately the archives don't have a search option and 
downloading them on my dial-up account takes ages :-( However, feel free to 
post links to sites or docs or whatever :-)

My main problem is understanding the order in which packets travel through 
the netfilter. After reading the docs my understanding of them was as 
follows. An incoming packet would first go into the nat's PREROUTING table, 
when it was destined for the local box it would then go to the fitler's INPUT 
table and after that to the process. If it was destined for another box it 
would go from PREROUTING => FORWARD => OUTPUT. It doesn't appear to work that 
way at all?!?! Unfortunately I didn't see anything about outgoing packets? So 
I'm totally in the dark on that one.

Anyways I wrote some rules like this:

iptables -A INPUT -j LOG --log-prefix "input-chain "
iptables -A FORWARD -j LOG --log-prefix "forward-chain "
iptables -A OUTPUT -j LOG --log-prefix "output-chain "
iptables -t nat -A PREROUTING -j LOG --log-prefix "prerouting-nat "
iptables -t nat -A POSTROUTING -j LOG --log-prefix "postrouting-nat "
iptables -t nat -A OUTPUT -j LOG --log-prefix "output-nat "

This was done on a box with IP adres 192.168.0.230, the DNS server is 
192.168.0.1 so is the gateway. I then fired up: lynx www.linuxdoc.org

This is what I got in my logs:

DNS Lookup request output:

Jan 31 09:32:13 www kernel: output-nat IN= OUT=eth0 SRC=192.168.0.230 
DST=192.168.0.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=20520 DF PROTO=UDP 
SPT=1045 DPT=53 LEN=42
Jan 31 09:32:13 www kernel: output-chain IN= OUT=eth0 SRC=192.168.0.230 
DST=192.168.0.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=20520 DF PROTO=UDP 
SPT=1045 DPT=53 LEN=42
Jan 31 09:32:13 www kernel: postrouting-nat IN= OUT=eth0 SRC=192.168.0.230 
DST=192.168.0.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=20520 DF PROTO=UDP 
SPT=1045 DPT=53 LEN=42

First it goes into the nat's output which I consider strange since this 
doesn't have to be natted in anyway. But ok, appearantly that's the way it 
is. Then it goes to the filter's output chain and then to nat's postrouting. 
I was under the assumption one of the 2 output chains would be the last one 
according to some drawings I've seen?....

DNS Answer:

Jan 31 09:32:13 www kernel: input-chain IN=eth0 OUT= 
MAC=00:01:03:26:f8:ba:00:30:ab:02:69:ec:08:00 SRC=192.168.0.1 
DST=192.168.0.230 LEN=306 TOS=0x00 PREC=0x00 TTL=64 ID=11679 PROTO=UDP SPT=53 
DPT=1045 LEN=286

This only hits the input-chain and nothing else.... According to the docs the 
PREROUTING chain would be the first to catch a packet? Where did it go?

Jan 31 09:32:13 www kernel: output-chain IN= OUT=eth0 SRC=192.168.0.230 
DST=192.168.0.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=20521 DF PROTO=UDP 
SPT=1045 DPT=53 LEN=42

Why there is another packet going to the DNS I don't know. Maybe it's some 
acknowledge or something, but that's not what I'm interested in. This packet 
only hit the filter's output chain? Where on earth did the other 2 chains go 
to? (nat's output en postrouting)

Jan 31 09:32:13 www kernel: input-chain IN=eth0 OUT= 
MAC=00:01:03:26:f8:ba:00:30:ab:02:69:ec:08:00 SRC=192.168.0.1 
DST=192.168.0.230 LEN=306 TOS=0x00 PREC=0x00 TTL=64 ID=11681 PROTO=UDP SPT=53 
DPT=1045 LEN=286

Another packet comes back from the DNS, again I miss the PREROUTING.....

Jan 31 09:32:13 www kernel: output-nat IN= OUT=eth0 SRC=192.168.0.230 
DST=152.2.210.81 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=12320 PROTO=TCP SPT=1887 
DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 31 09:32:13 www kernel: output-chain IN= OUT=eth0 SRC=192.168.0.230 
DST=152.2.210.81 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=12320 PROTO=TCP SPT=1887 
DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 31 09:32:13 www kernel: postrouting-nat IN= OUT=eth0 SRC=192.168.0.230 
DST=152.2.210.81 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=10736 DF PROTO=TCP 
SPT=1887 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

K here we build up a connection to the webserver. I feel pretty safe now to 
say that only the first outgoing packet passes the 3 chains, or atleast, when 
no NAT is being performed. Can anyone enlighten me on what happens if the 
connection is NAT'ed? Will the packets keep on going through all chains then? 
This matters because I want to setup a DENY policy on ALL 6 default chains. 
Else, I only have to allow syn packets through the nat's output and 
POSTROUTING right?

Jan 31 09:32:13 www kernel: input-chain IN=eth0 OUT= 
MAC=00:01:03:26:f8:ba:00:30:ab:02:69:ec:08:00 SRC=152.2.210.81 
DST=192.168.0.230 LEN=44 TOS=0x00 PREC=0x00 TTL=46 ID=15207 DF PROTO=TCP 
SPT=80 DPT=1887 WINDOW=32767 RES=0x00 ACK SYN URGP=0

Again we only hit the input chain

Jan 31 09:32:13 www kernel: output-chain IN= OUT=eth0 SRC=192.168.0.230 
DST=152.2.210.81 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=16028 PROTO=TCP SPT=1887 
DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0

And only the output chain

I'll spare you the rest of the log, it's nothing but input, output, input, 
output, input, output anyways with the only thing changing the ID and 
ofcourse at the last packets then LEN value cuz the last packets aren't 
completely filled. Anyways, I'm totally lost on the traversal through these 
chains now and I find it strange that for traffic that doesn't need to be 
mangled/masqed/nat'ed chains in the nat table are used...

Anyways I also have some comments/questions on the Packet Filtering HOWTO

In point 7.3.6.4 there is a diagram to help you understand the limit option. 
In there it says Edge of DoS = (limit * limit-burst). If I understand things 
correctly that is NOT true. This would mean that if I set a limit of 5 and a 
burst of 15 both values per sec 75 packets would be let through in the first 
second, whilst I believe this is only 15. Then after 1 sec / 5 = 0.2 secs 
another packets would be let through. After another 0.2 secs another packet 
would be let through (assuming there is a continuous stream of packets of 
course) If the traffic would fall still for 1 sec There should be allowed 
another 5 packets the next sec (assuming they come in as fast as possible) 
After 3 secs of no traffic the burst should be recharged and then the first 
time 15 packets a sec would be allowed. Or atleast, that is my take on it.... 
Perhaps the difference between the limit and the burst limit is just really 
unclear to me? Please enlighten me.

In point 11 almost at the end there's a no-conns-from-ppp0 chain in which 
there are two lines. Beware, this might be nag mode :-).
These are the two lines:
iptables -A no-conns-from-ppp0 -i ppp0 -m limit -j LOG --log-prefix "Bad 
traffic "
iptables -A no-conns-from-ppp0 -i ! ppp0 -m limit -j LOG --log-prefix "Bad 
traffic "

Is there any reason for that to be 2 lines? Cuz in my eyes you could just 
make the -i match any interface right away which would be better considering 
the lines below that stating "always be a minimalist" but... that's just 
nagging. Anyways, I was thus wondering why it was written in 2 lines? Any 
reason for that?

Also I remember something about a statement that the -i could only be 
specified in the INPUT and FORWARD chains. However it works on the PREROUTING 
chain as well as I expected. But I could be mistaken here, or perhaps I 
misread. I can't find it back anymore this fast.

Anyways, my main concern is the chain traversal order. In need to know how 
packets traversal in the cases:
Input is destined for local box
output coming from local box
input destined for a box on the local network on a NAT'ed connection
output destined for the internet coming from a client behind the box needing 
to be NAT'ed.

I know the SNAT is done in the POSTROUTING chain. Also, what's the difference 
exactly between the MASQUERADE target and the SNAT target? The only 
difference I can find is that you use MASQUERADE on a dynamic IP interface so 
you don't have to change the IP address every time which I think you would 
have to do with the SNAT target. Is that correct?

Sorry for the extremely long email. Hoping I can figure this out tomorrow so 
I can get back to my other business. 

Thanks in advance and kind regards and I hope I expressed myself clearly :-)

Ferry van Steen

PS yesterday I sent in a comment on ICQ and I got a reply from somebody 
stating he had tried that but it didn't work. I'll look into it at home and 
since I have to write the complete thing down anyways I might as well make it 
in html or whatever... Anyone I can send it to so it can be added to the 
howto/faq/whatever? I can only deliver it in HTML or .txt, I have no 
experience with SGML n stuff.

Regards