libn/d/overlay: stop programming INPUT ACCEPT rule

Encrypted overlay networks are unique in that they are the only kind of
network for which libnetwork programs an iptables rule to explicitly
accept incoming packets. No other network driver does this. The overlay
driver doesn't even do this for unencrypted networks!

Because the ACCEPT rule is appended to the end of INPUT table rather
than inserted at the front, the rule can be entirely inert on many
common configurations. For example, FirewallD programs an unconditional
REJECT rule at the end of the INPUT table, so any ACCEPT rules appended
after it have no effect. And on systems where the rule is effective, its
presence may subvert the administrator's intentions. In particular,
automatically appending the ACCEPT rule could allow incoming traffic
which the administrator was expecting to be dropped implicitly with a
default-DROP policy.

Let the administrator always have the final say in how incoming
encrypted overlay packets are filtered by no longer automatically
programming INPUT ACCEPT iptables rules for them.

Signed-off-by: Cory Snider <csnider@mirantis.com>

libnetwork/drivers/overlay/encryption.go

@@ -300,12 +300,6 @@ var programInput = programVXLANRuleFunc(func(matchVXLAN matchVXLANFunc, vni uint
 		return a
 	}
 
-	// Accept incoming VXLAN datagrams for the VNI which were subjected to IPSec processing.
-	// Append to the bottom of the chain to give administrator-configured rules precedence.
-	if err := iptable.ProgramRule(iptables.Filter, chain, action(iptables.Append), rule("ipsec", "ACCEPT")); err != nil {
-		return fmt.Errorf("could not %s input accept rule: %w", msg, err)
-	}
-
 	// Drop incoming VXLAN datagrams for the VNI which were received in cleartext.
 	// Insert at the top of the chain so the packets are dropped even if an
 	// administrator-configured rule exists which would otherwise unconditionally