yahoo-eng-team team mailing list archive

[Armando Migliaccio <1609481@xxxxxxxxxxxxxxxxxx>]

http://lists.openstack.org/pipermail/openstack-
dev/2016-November/107384.html

** Changed in: neutron
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1609481

Title:
  [VPNaaS]  Strongswan can't work with Neutron metering

Status in neutron:
  Won't Fix

Bug description:
  With openswan backend, we can use neutron metering to do the IPsec
  traffic counting as follow:

  1. create the metering labels & metering label rules for the remote subnet of the ipsec connection you want to bring up.
  2. create the ipsec connection as normal.
  3. use ceilometer commands to get the counter details of the metering label.

  However, when we use strongswan as backend, there is issue for VPN
  service to use neutron metering to do the traffic counting. It's
  because strongswan and neutron metering will both compete to write
  it's own rules in FOWARD chain of filter table.

  Strongswan side:
  With the current configure option "leftfirewall=yes", when ipsec connection up it will write 2 iptables rules to accept the IPsec selectors traffic in FORWARD chain of filter table in the namespace. Actually it calls "iptabels -I FORWARD 1 *****  -j ACCEPT" to make sure these 2 chains are on the top of chain FORWARD.

  Neutron metering side:
  It will also write its label rules to the FORWARD chain of filter table when we enable.

  So for these 2, the one who are later to write the rules, who are be
  the top of FORWARD chain. And the target of strongswan rules are
  "ACCEPT", it's known that once the packet match the "ACCEPT" rules, it
  won't go to any other following rules in FORWARD chain. Then if we do
  as the steps for openswan, then the issue comes: metering rule can't
  got any traffic counting at all. Even we create the metering label
  rules after we configure the ipsec connection, it still has issue,
  because strongswan's rules are applied only when the ipsec connection
  being established/up. We can't control the connection up time with its
  peer. So the above issue still exists. For this case, the details of
  FOWARD chain shown as following:

  Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target     prot opt in     out     source               destination
      9   756 ACCEPT     all  --  qg-5f335626-4b *       192.168.200.0/24     192.168.100.0/24     policy match dir in pol ipsec reqid 1 proto 50
      0     0 ACCEPT     all  --  *      qg-5f335626-4b  192.168.100.0/24     192.168.200.0/24     policy match dir out pol ipsec reqid 1 proto 50
      0     0 neutron-filter-top  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      0     0 neutron-vpn-agen-FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      0     0 neutron-meter-FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0

  What's more, i notice that there are cases that the strongswan's
  iptables rules can be written duplicate since the script called by
  "leftfirewall" won't check the existing rules in the FORWARD chain but
  just add it as the index 1(unlucky can't reproduce the case).

  The above issue can be simply solved by disable the 'leftfirewall'
  option. The aim for user to enable "leftfirewall" is to make sure the
  IPsec selector traffic won't block/drop by any other iptables. Then we
  should think about the necessary of FW rules on the VPN router
  namespace to decide whether to disable this option or not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1609481/+subscriptions