yahoo-eng-team team mailing list archive

Thread
Date

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

To: yahoo-eng-team@xxxxxxxxxxxxxxxxxxx
From: Jin Jing Lin <1609481@xxxxxxxxxxxxxxxxxx>
Date: Wed, 03 Aug 2016 16:24:07 -0000
Reply-to: Bug 1609481 <1609481@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx

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:

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:

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.

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:

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

[Bug 1609481] Re: [VPNaaS] Strongswan can't work with Neutron metering
From: Armando Migliaccio, 2016-11-17