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
