# iptables again - allowed packets are dropped sometimes

## Jimini

Yep, it's me again, and again I'm having some trouble with iptables :\

The problem is, that the firewall seems to drop packets that should be allowed to pass.

1) I have an IRCD running on my box, these are my (relevant) rules:

```
# default policy: drop everything

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

# accept local traffic

iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

# accept all traffic belonging to an established connection

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# IRCD

iptables -A INPUT -p tcp --dport 6667 -j ACCEPT

# drop and log the rest

iptables -A INPUT -j LOG --log-prefix "DROPPED_INPUT: " --log-level=5

iptables -A INPUT -j DROP

iptables -A OUTPUT -j LOG --log-prefix "DROPPED_OUTPUT: " --log-level=5

iptables -A OUTPUT -j DROP

iptables -A FORWARD -j LOG --log-prefix "DROPPED_FORWARD: " --log-level=5

iptables -A FORWARD -j DROP
```

This should suffice, shouldn't it? But:

```
IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=57246 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=57246 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=57246 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=57246 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=57246 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=57246 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.100 LEN=351 TOS=0x00 PREC=0x00 TTL=64 ID=45190 DF PROTO=TCP SPT=6667 DPT=54452 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.77.127 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=54452 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.77.127 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=54452 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.77.127 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=54452 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.77.127 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=54452 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.77.127 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=54452 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.88 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=64129 WINDOW=0 RES=0x00 RST URGP=0                                     

IN= OUT=eth0 SRC=MY_IP DST=77.176.84.88 LEN=350 TOS=0x00 PREC=0x00 TTL=64 ID=57133 DF PROTO=TCP SPT=6667 DPT=53490 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0                     

IN= OUT=eth0 SRC=MY_IP DST=77.176.82.242 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=53490 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.82.242 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=53490 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.82.242 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=6667 DPT=53644 WINDOW=0 RES=0x00 RST URGP=0                                    

IN= OUT=eth0 SRC=MY_IP DST=77.176.82.242 LEN=377 TOS=0x00 PREC=0x00 TTL=64 ID=4655 DF PROTO=TCP SPT=6667 DPT=57338 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
```

These packets were logged from november 1st until today and at completely different times of the day. No one of my friends complains about problems with connecting to the server. The entries also occur at times, where no one is online (in the middle of the night for example).

2) Since a few weeks my logfile, where the dropped input-traffic is written into, contains many packets from port 80. I whois'd the source-IP - the packets often come from servers I know. But they should have the status "established" - I just can not explain why they are dropped. 

This log contains dropped traffic to port 20530, too - but these packets should also be allowed:

[code]iptables -A FORWARD -p tcp --dport 20530 -m state --state NEW -j ACCEPT

iptables -t nat -I PREROUTING -i $wan -p tcp --dport 20530 -j DNAT --to-destination 10.0.0.2:20530[quote]

Sometimes, they come from 192.168.0.101 (and come from the internet) which seems like a martian then. But my syslog does not contain these packets, although log_martians is set on "1"...

All my connections seems to work really well so far - I only would like to know, why these packets can not pass my firewall.

Any ideas or hints would really really be appreciated!

Best regards,

Jimini

----------

## patrix_neo

I've read that the more specific your iptables commands are, the better. Like:

```
iptables -A INPUT -i ethX -p tcp --dport 6667 -s 0/0 -d $IP -j ACCEPT
```

----------

## Hu

Those RST packets are expected, but not very desirable.  You restricted OUTPUT rather heavily, so if a connection is torn down, then a spurious packet shows up late, your system is unable to emit the RST because of your restrictive OUTPUT chain.

For your second point, it would help to see the exact packet as printed by the kernel.

----------

## Jimini

 *patrix_neo wrote:*   

> I've read that the more specific your iptables commands are, the better. Like:
> 
> ```
> iptables -A INPUT -i ethX -p tcp --dport 6667 -s 0/0 -d $IP -j ACCEPT
> ```
> ...

 

I want to reach the server from the outside and also from my network, so I would have to create two rules instead of one. Or do you think my rule is simply wrong?

 *Hu wrote:*   

> Those RST packets are expected, but not very desirable.  You restricted OUTPUT rather heavily, so if a connection is torn down, then a spurious packet shows up late, your system is unable to emit the RST because of your restrictive OUTPUT chain.

 

This makes sense. But I have compared the target IP address with the ones in the ICRD's logfile - none of the connected clients matches. I also know the ISP of all of my friends - no one uses O2 / Telefonica.

For your second point, it would help to see the exact packet as printed by the kernel.[/quote]

Here you are:

```
IN=eth0 OUT= MAC=00:27:0e:08:f1:8d:00:01:5c:31:19:40:08:00 SRC=66.220.145.41 DST=MY_IP LEN=874 TOS=0x00 PREC=0x00 TTL=244 ID=45515 DF PROTO=TCP SPT=80 DPT=45455 WINDOW=17 RES=0x00 ACK PSH URGP=0 

IN=eth0 OUT= MAC=00:27:0e:08:f1:8d:00:01:5c:31:19:40:08:00 SRC=66.220.145.41 DST=MY_IP LEN=874 TOS=0x00 PREC=0x00 TTL=244 ID=45516 DF PROTO=TCP SPT=80 DPT=45455 WINDOW=17 RES=0x00 ACK PSH URGP=0 

IN=eth0 OUT= MAC=00:27:0e:08:f1:8d:00:01:5c:31:19:40:08:00 SRC=66.220.145.41 DST=MY_IP LEN=874 TOS=0x00 PREC=0x00 TTL=244 ID=45517 DF PROTO=TCP SPT=80 DPT=45455 WINDOW=17 RES=0x00 ACK PSH URGP=0 

IN=eth0 OUT= MAC=00:27:0e:08:f1:8d:00:01:5c:31:19:40:08:00 SRC=66.220.145.41 DST=MY_IP LEN=874 TOS=0x00 PREC=0x00 TTL=244 ID=45518 DF PROTO=TCP SPT=80 DPT=45455 WINDOW=17 RES=0x00 ACK PSH URGP=0
```

Best regards,

Jimini

----------

## Hu

Regarding ISPs: no idea then.

Regarding the port 80 issue: this is probably just noise from connections that were closed before all the traffic was flushed.  TCP normally handles this gracefully, but packets associated with a connection that has been removed from conntrack might exhibit this problem.

----------

## Jimini

At least, I found the - really stupid - reason for the dropped packets from my IRC-daemon. One user never ends the connection cleanly, he quits from the server by shutting down his machine, so he pings out. I assume, that my daemon then tries to reach his client, which is unreachable, so this connection has lost the status "established". My server is not allow to begin a connection by itself, so the packets are dropped. I would have found this reason earlier, if "whois" would not have listed the wrong ISP for his address.

Best regards,

Jimini

----------

