2

I'm noticing some blocked packets in my iptables log when running a python library that calls paramiko. I noticed the blocked packets when trying to figure out why there is inconsistent network performance with this library when iptables is running. Basically, the server (10.0.12.206 in the log below) runs the library which uses paramiko to execute commands securely on the client (10.0.10.103 in the log below) over port 22. When the client is running permissive iptables, it works pretty well. When the client runs iptables with the rules below, there are typically indefinite hangs, and I suspect it might be due to some packets getting blocked by iptables running on the client, since these packets only appear in the log when the library is running.

These are my iptables rules-

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

-A INPUT -i lo -j -ACCEPT
-A OUTPUT -o lo -j -ACCEPT

-A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

-A OUTPUT -o eth0 -p udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT

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

-A INPUT -j LOG --log-prefix "IPtables DROP DEFAULT IN: " 
-A OUTPUT -j LOG --log-prefix "IPtables DROP DEFAULT OUT: " 

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

These are the usual messages in the client log-

Oct  7 16:43:08 ip-10-0-10-103 kernel: IPtables DROP DEFAULT IN: IN=eth0 OUT= MAC=<withheld> SRC=10.0.12.206 DST=10.0.10.103 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=18436 DF PROTO=TCP SPT=58634 DPT=22 WINDOW=523 RES=0x00 ACK FIN URGP=0

Oct  7 16:44:14 ip-10-0-10-103 kernel: IPtables DROP DEFAULT OUT: IN= OUT=eth0 SRC=10.0.10.103 DST=10.0.12.206 LEN=260 TOS=0x00 PREC=0x00 TTL=64 ID=57627 DF PROTO=TCP SPT=22 DPT=58634 WINDOW=240 RES=0x00 ACK PSH URGP=0

I'd like to see if these blocked packets are causing the trouble. How do I allow these blocked packets to pass? I tried a couple of rules but had no luck, e.g.-

-A OUTPUT -o eth0 -p tcp --tcp-flags ALL ACK,PSH,URG -j ACCEPT
Improve this question
1
  • 1
    Instead of using iptables rules directly, consider using a firewall management solution like shorewall or ufw. They take care of the pitfalls like this when setting up rules.
    – Tero Kilkanen
    Oct 8, 2016 at 15:21

1 Answer 1

Reset to default
1

I think the problem is that you are allowing OUTPUT to port 22, but it should be coming from port 22:

-A OUTPUT -o eth0 -p tcp --sport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

This should fix the second log line you posted. I'm not sure why the first packet you logged is getting caught though. Can you check iptables -nvL and make sure these rules are actually getting applied?

Improve this answer
1
  • Thanks very much for your help. That fixed it. (And yes, the rules were definitely getting applied as per iptables nvL).
    – hotkarl
    Oct 10, 2016 at 14:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .