The east/west case is the only case with this asymmetric routing problem being discussed. However, the north/south case might still be interesting from a FWaaS perspective. The fact that the router is distributed in pieces may affect it depending on the firewall implementation.
Carl On Jun 28, 2014 10:27 PM, "Richard Woo" <richardwoo2...@gmail.com> wrote: > Regarding of user case of this feature, are you referring E-W traffic or > N-S traffic? > > > On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun <beyo...@gmail.com> wrote: > >> All, >> During last summit, we were talking about the integration issues between >> DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But >> after that meeting I was tight up with my work and did not get time to >> continue to follow up the issue. To not slow down the discussion, I'm >> forwarding out the email that I sent out as the follow up to the IRC >> meeting here, so that whoever may be interested on the topic can continue >> to discuss about it. >> >> First some background about the issue: >> In the normal case, FW and router are running together inside the same >> box so that FW can get route and NAT information from the router component. >> And in order to have FW to function correctly, FW needs to see the both >> directions of the traffic. >> DVR is designed in an asymmetric way that each DVR only sees one leg of >> the traffic. If we build FW on top of DVR, then FW functionality will be >> broken. We need to find a good method to have FW to work with DVR. >> >> ---forwarding email--- >> During the IRC meeting, we think that we could force the traffic to the >> FW before DVR. Vivek had more detail; He thinks that since the br-int >> knowns whether a packet is routed or switched, it is possible for the >> br-int to forward traffic to FW before it forwards to DVR. The whole >> forwarding process can be operated as part of service-chain operation. And >> there could be a FWaaS driver that understands the DVR configuration to >> setup OVS flows on the br-int. >> The concern is that normally firewall and router are integrated together >> so that firewall can make right decision based on the routing result. But >> what we are suggesting is to split the firewall and router into two >> separated components, hence there could be issues. For example, FW will >> not be able to get enough information to setup zone. Normally Zone contains >> a group of interfaces that can be used in the firewall policy to enforce >> the direction of the policy. If we forward traffic to firewall before DVR, >> then we can only create policy based on subnets not the interface. >> Also, I’m not sure if we have ever planed to support SNAT on the DVR, but >> if we do, then it depends on at which point we forward traffic to the FW, >> the subnet may not even work for us anymore (even DNAT could have problem >> too). >> Another thing that I may have to get detail is that how we handle the >> overlap subnet, it seems that the new namespaces are required. >> >> --- end of forwarding ---- >> >> YI >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
