<h2>Context</h2>
<p>Maybe there is unnecessary redundancy in the <code>iptables</code> rules generated by <code>kubeadm init</code> for <code>kube-proxy</code>:</p>
<pre><code>iptables -t filter -S
</code></pre>
<p>output:</p>
<pre><code>-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N KUBE-EXTERNAL-SERVICES
-N KUBE-FIREWALL
-N KUBE-FORWARD
-N KUBE-SERVICES
-A INPUT -m conntrack --ctstate NEW -m comment --comment &quot;kubernetes externally-visible service portals&quot; -j KUBE-EXTERNAL-SERVICES
-A INPUT -j KUBE-FIREWALL
-A FORWARD -m comment --comment &quot;kubernetes forwarding rules&quot; -j KUBE-FORWARD
-A FORWARD -s 10.244.0.0/16 -j ACCEPT
-A FORWARD -d 10.244.0.0/16 -j ACCEPT
-A OUTPUT -m conntrack --ctstate NEW -m comment --comment &quot;kubernetes service portals&quot; -j KUBE-SERVICES
-A OUTPUT -j KUBE-FIREWALL
-A KUBE-FIREWALL -m comment --comment &quot;kubernetes firewall for dropping marked packets&quot; -m mark --mark 0x8000/0x8000 -j DROP
-A KUBE-FORWARD -m comment --comment &quot;kubernetes forwarding rules&quot; -m mark --mark 0x4000/0x4000 -j ACCEPT
-A KUBE-FORWARD -s 10.244.0.0/16 -m comment --comment &quot;kubernetes forwarding conntrack pod source rule&quot; -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A KUBE-FORWARD -d 10.244.0.0/16 -m comment --comment &quot;kubernetes forwarding conntrack pod destination rule&quot; -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
</code></pre>
<p>The <code>10.244.0.0/16</code> range corresponds to the pod overlay network.</p>
<p>Lets focus on the <code>FORWARD</code> chain.</p>
<pre><code>-P FORWARD DROP
-N KUBE-FORWARD
-A FORWARD -m comment --comment &quot;kubernetes forwarding rules&quot; -j KUBE-FORWARD
-A FORWARD -s 10.244.0.0/16 -j ACCEPT
-A FORWARD -d 10.244.0.0/16 -j ACCEPT
-A KUBE-FORWARD -m comment --comment &quot;kubernetes forwarding rules&quot; -m mark --mark 0x4000/0x4000 -j ACCEPT
-A KUBE-FORWARD -s 10.244.0.0/16 -m comment --comment &quot;kubernetes forwarding conntrack pod source rule&quot; -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A KUBE-FORWARD -d 10.244.0.0/16 -m comment --comment &quot;kubernetes forwarding conntrack pod destination rule&quot; -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
</code></pre>
<h2>Question:</h2>
<p>Why the <code>KUBE-FORWARD</code> accepts packages within the overlay network, when their connection state is <code>RELATED</code> or <code>ESTABLISHED</code> if <code>FORWARD</code> chain will accept all packet traffic within the overlay network regardless their connection state?</p>
<h2>Note:</h2>
<p>The kubernetes cluster works fine.</p>

<p>This duplication is there, because the default FORWARD policy can be disabled for some reason, and Kubernetes still wants to forward packets that either:</p>

<ol>
<li>Are marked with "masqueradeMark" (those can start new connections)</li>
<li>Are part of already established connection</li>
</ol>

<p>You can try reading the comments in the k8s source: <a href="https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/iptables/proxier.go#L1325" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/iptables/proxier.go#L1325</a></p>

<p>In general, one should expect some duplication in iptables rules when those rules are automatically managed. It makes it easier to code the automation.</p>
