Quote:
Originally Posted by heberrdacruz
I have listed below all the FORWARD drops form yesterday, which again I don?t understand.
|
I don't know what is going on either, but I do have some observations about the dropped packets on the FORWARD chain.
There were two packets which both entered and exited on eth0 when the address would indicate it should come in on eth1:
Code:
Aug 17 11:04:40 newton kernel: FORWARD DROP: IN=eth0 OUT=eth0 SRC=192.168.30.108 DST=200.17.114.40 LEN=105 TOS=0x00 PREC=0x00 TTL=127 ID=6300 PROTO=UDP SPT=1588 DPT=53 LEN=85
Aug 17 11:13:24 newton kernel: FORWARD DROP: IN=eth0 OUT=eth0 SRC=192.168.30.92 DST=65.54.179.228 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=39322 DF PROTO=TCP SPT=48758 DPT=443 WINDOW=2573 RES=0x00 ACK FIN URGP=0
Of the others, most have the ACK and FIN flags set, and except for three packets, all of the rest have the RST (reset) flag set, either with or without the ACK flag set.
The three that don't meet any of the above criteria are:
Code:
Aug 17 14:15:23 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.136 DST=207.46.24.46 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=1668 PROTO=TCP SPT=3288 DPT=1863 WINDOW=0 RES=0x00 ACK URGP=0
Aug 17 14:15:37 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.136 DST=207.46.24.46 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=1703 PROTO=TCP SPT=3288 DPT=1863 WINDOW=0 RES=0x00 ACK URGP=0
Aug 17 14:15:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.136 DST=207.46.24.46 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=1754 PROTO=TCP SPT=3288 DPT=1863 WINDOW=0 RES=0x00 ACK URGP=0
Win32sux and I previously debated a situation with the FIN and ACK flags set. I don't think we came to any definitive decision. But both the FIN flag and RST flag have to do with a connection shutting down one way or the other. Maybe somebody else viewing this thread can come up with an explanation.
Also, heberrdacruz, I don't know how much you know about the tools in the Unix world, so forgive me if you already know this, but the
grep command can come in quite handy in sorting through data like this.
EDIT:
ipchains had the ability to adjust the timing parameters used in MASQueraded connections. I am unaware of any such ability in
iptables to adjust the timing parameters for MASQUERADEd or SNATed connections. Does anybody know if there is a way to do that and whether it might have any bearing on the situation described here?