Mesos CNI portmap plugins' iptables rules doesn't allow connections via host ip and port from the same bridge container network

using `mesos-cni-port-mapper` with folllowing config:

{ 
   "name" : "dcos", 
   "type" : "mesos-cni-port-mapper", 
   "excludeDevices" : [], 
   "chain": "MESOS-CNI0-PORT-MAPPER", 
   "delegate": { 
       "type": "bridge", 
       "bridge": "mesos-cni0", 
       "isGateway": true, 
       "ipMasq": true, 
       "hairpinMode": true, 
       "ipam": { 
           "type": "host-local", 
           "ranges": [ 
               [{"subnet": "172.26.0.0/16"}] 
           ], 
           "routes": [ 
               {"dst": "0.0.0.0/0"} 
           ] 
       } 
   } 
}

• 2 services running on the same mesos-slave using unified containerizer in different tasks and communicating via host ip and host port
• connection timeouts due to iptables rules per container CNI-XXX chain
• actually timeouts are caused by

  Chain CNI-XXX (1 references)
  num  target     prot opt source               destination         
  1    ACCEPT     all  --  anywhere             172.26.0.0/16        /* name: "dcos" id: "YYYY" */
  2    MASQUERADE  all  --  anywhere            !base-address.mcast.net/4  /* name: "dcos" id: "YYYY" */
  

  rule #1 is executed and no masquerading happens.

there are multiple solutions:

• simpliest and fastest one is not to add that ACCEPT - NOT A SOLUTION. it's happening in `bridge` plugin and `cni/portmap` shows that snat/masquerade should be done during portmapping as well.
• perhaps, there's a better change in iptables rules that can fix it
• proper one (imho) is to finally implement cni spec 0.3.x in order to be able to use chaining of plugins and use cni's `bridge` and `portmap` plugins in chain (and get rid of mesos-cni-port-mapper completely eventually).