1. Home
  2. Networking Firewalls
  3. Strange dropped packages - guarddog/iptables

Strange dropped packages - guarddog/iptables

Hi!

I am running Gentoo linux. After installing and setting guarddog, I found the following "strange", at least for me, situations:

  1. There are lots of dropped packets like this one towards various sites

Ex.: DROPPED IN= OUT=wlan0 SRC=192.168.1.xx DST=209.85.229.149 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=16475 DF PROTO=TCP SPT=4504 DPT=80 SEQ=1247115119 ACK=2605117908 WINDOW=191 RES=0x00 ACK FIN URGP=0

What are these packets and why are they being rejected? I don't notice any problem in my accesses to my local net nor the "outside world".

  1. On every boot of my laptop, and only then, I got the following 4 packets (source port changes):

DROPPED IN= OUT=wlan0 SRC=192.168.1.xx DST=192.168.1.99 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19798 DF PROTO=TCP SPT=2334 DPT=80 SEQ=602150045 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40101040201030307)

DROPPED IN= OUT=wlan0 SRC=192.168.1.xx DST=192.168.1.99 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19799 DF PROTO=TCP SPT=2334 DPT=80 SEQ=602150045 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40101040201030307)

DROPPED IN= OUT=wlan0 SRC=192.168.1.xx DST=192.168.1.99 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19800 DF PROTO=TCP SPT=2334 DPT=80 SEQ=602150045 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40101040201030307)

DROPPED IN= OUT=wlan0 SRC=192.168.1.xx DST=192.168.1.99 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=3738 DF PROTO=TCP SPT=2342 DPT=80 SEQ=914204314 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40101040201030307)

This is even more strange because 192.168.1.99 is not an address that I use in my local network and this situation does not occur on, for example, another PC (desktop) I have and it has the same SW and very similar configuration!

192.168.1.xx is the IP address of the PC and xx is not 99.

Thanks for any help/comments.

Reply to
Paulo da Silva
Loading thread data ...

Probably your browser closing a connection to Google.

formatting link

We wouldn't know, since you omitted your ruleset.

That's because even if the connection isn't terminated correctly, it will expire after some time.

I don't know of a straightforward way to do this with iptables, but you could use the owner-match module and add logging rules for processes that you suspect might generate this. See [1].

[1]
formatting link
F'up2csf

cu

59cobalt
Reply to
Ansgar -59cobalt- Wiechers

Hello,

Ansgar -59cobalt- Wiechers a écrit :

[...]

Probably because the packet is classified in the INVALID state by the connection tracking and there is a rule which DROPs such packets.

The --pid-owner, --sid-owner and --cmd-owner options have been deprecated and removed in kernel 2.6.14 and above.

Reply to
Pascal Hambourg

Since those packets are an initial SYN, if you can catch it quickly enough, you can probably do

netstat -nap

to get the SYN_SENT line with the process ID. Then pstree to trace what started it. Once it quits trying, though, there's nothing left to analyze.

Reply to
Allen Kistler

Thanks. Is there any inconvenience to let this happen? As I said, the ruleset was written by guarddog. Any rule to allow *only* these packets without compromising the rest of the ruleset?

Reply to
Paulo da Silva

Ansgar -59cobalt- Wiechers escreveu: ...

I found the reason. A html document I have opened in konqueror has 4 references to 192.168.1.99. Somehow who wrote it forgot those refs there. In fact the "problem" occurs when I login and not as part of the boot process as I thought first.

Thank you all for answering.

Reply to
Paulo da Silva

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.