← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1609481] [NEW] [VPNaaS] [VPNaaS] Strongswan can't work with Neutron metering

 

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
         Status: New

** Description changed:

  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. 
+ 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. 
+ 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 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. Even we create the metering label rules after we configure the ipsec connection, it still has issue, becasue the strongswan's rules are applied 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:
+ 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).  
+  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 that need FW rules on the VPN router
- namespace to decide whether to disable this option or not.
+ should think about the necessary of FW rules on the VPN router namespace
+ to decide whether to disable this option or not.

-- 
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]  [VPNaaS]  Strongswan can't work with Neutron metering

Status in neutron:
  New

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


Follow ups