We have routable floating IPs for the various services that get assigned dynamically as aliases on a (non-loopback) device. No NAT is being done for these currently.
On Thu, Jun 18, 2015 at 1:57 PM, Shaun Crampton < shaun.cramp...@metaswitch.com> wrote: > Sorry Nick, I think we missed that use-case when tightening up those > rules but I think it’s something that we want to support. > > I’ve filed a Github issue to track this: > https://github.com/Metaswitch/calico/issues/659. > > How are you exposing the services, are you running them on 127.0.0.1 (or > 0.0.0.0) and then NATing or is the VM just talking to the host on its > external IP address? > > Thanks, > > -Shaun > > From: Nick Bartos <n...@pistoncloud.com> > Date: Thursday, 18 June 2015 13:30 > To: "calico-tech@lists.projectcalico.org" < > calico-tech@lists.projectcalico.org> > Subject: Re: [calico-tech] Problem with new iptables rules in > calico/master > > Actually now that I think about it, changing the insert order is still > sub-optimal as this means that the security policy for the VM will be > bypassed for those rules. It seems like the security group rules still > need to be applied on INPUT, not just forward. > > On Thu, Jun 18, 2015 at 1:24 PM, Nick Bartos <n...@pistoncloud.com> wrote: > >> A very recent change modified the input iptables rules. However, this >> resulted in an unfortunate situation. >> >> The felix rules ("INPUT -j felix-INPUT", "FORWARD -j felix-FORWARD") >> are inserted to the top of the chain, preempting any rules that were set >> before it. Later in the felix input rule, there is this: >> >> -A felix-INPUT -m conntrack --ctstate INVALID -j DROP >> -A felix-INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT >> -A felix-INPUT -d 127.0.0.1/32 -i tap+ -p tcp -m tcp --dport 8775 -j >> ACCEPT >> -A felix-INPUT -i tap+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT >> -A felix-INPUT -i tap+ -j DROP >> >> This basically means any previous allow rules on the input chain from >> the VMs are disregarded. This is a problem for us as we run some services >> locally on the hypervisors that the VMs need to be able to talk to. >> >> While this was sort of the case with the forward chain before, it was >> generally fine, since the outbound security policy was respected (which for >> most cases is allow). >> >> Is there a way to get the felix-INPUT (and maybe the felix-FORWARD) >> jumps to be inserted further down the list (although putting it way down at >> the bottom wouldn't work for us as we have a debug log for the catch-all >> policy drop there)? Or can you think of another solution? >> > >
_______________________________________________ calico-tech mailing list calico-tech@lists.projectcalico.org http://lists.projectcalico.org/listinfo/calico-tech
