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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp