Christian <syphdias+archlinuxml@gmail.com> wrote:
https://netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html , are you saying
A program running on the box can send network packets. These packets pass through the OUTPUT chain only if the INPUT chain allows it
?
If you do, note my understanding of statement 4 at buttom of the link is different. Am I wrong?
You are correct. I was wrong. You can even see it in the flow diagram I linked [1]. Thank you for pointing that out!
If it was on a separate router/firewall machine the reasoning would hold, I think. Please correct me if I am wrong!
Quting https://netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html a program running on the box can send network packets. These packets pass through the OUTPUT chain immediately As it says. No matter if this is a desktop, laptop, router, firewall. A local process sending packets passes its packets to the OUTPUT chain immediately. As a side note, the title of the link is How Packets Traverse The Filters. It could be you are confused because there is an indirect interaction between packets in the OUTPUT and INPUT chains. If a process is sending packets to www.archlinux.org in the OUTPUT chain, but blocks www.archlinux.org in the INPUT chain, it could have thought its packets didn't went out. Which is not the case. The fact that the process blocks the replies doesn't necessarily prove www.archlinux.org didn't reply. Furthere more, the order of the rules matter. With pseudo rules, www.archlinux.org drop www.archlinux.org {ESTABLISHED,RELATED} accept has different semantics then www.archlinux.org {ESTABLISHED,RELATED} accept www.archlinux.org drop And the drop rule in the later example is not necessarily with no effect. It is meaningless at the former example. -- u34
I guess, it is back to not understanding why blocking inbound connections would be a problem for outbound connections.
Best, Christian
[1]: https://en.wikipedia.org/wiki/Iptables#/media/File:Netfilter-packet-flow.svg