yahoo-eng-team team mailing list archive

[James Dempsey <jamesd@xxxxxxxxxxxxxxx>]

Public bug reported:

I'm using the Icehouse UCA version 1:2014.1.3-0ubuntu1~cloud0 of the
VPN(openswan driver) and Metering(iptables driver) agents on Ubuntu
Precise.

The ordering of the POSTROUTING chain in the NAT table inside router
namespaces seems to be broken.  In many of my routers, the neutron-
postrouting-bottom rule is listed before the neutron-vpn-agen-
POSTROUTING rule.  This causes traffic that should have traversed a VPN
to be Source NAT'd as if it were traffic leaving via the default route.
Rescheduling the router or removing metering rules for it seem to cause
a re-ordering of rules.

It seems to me that neutron-postrouting-bottom should always be the last
rule in the POSTROUTING chain.  Is this correct?

In the following state, VPNs are broken regardless of the existence of
Phase 1 and Phase 2 IPsec

Chain POSTROUTING (policy ACCEPT 2194K packets, 129M bytes)
 pkts bytes target     prot opt in     out     source               destination         
2199K  129M neutron-meter-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2568K  152M neutron-postrouting-bottom  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2563K  151M neutron-vpn-agen-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0      

Removing metering rules can cause the above chain to be changed into the
following, which I assume (but have not verified) would break metering,
were it enabled.

Chain POSTROUTING (policy ACCEPT 2199K packets, 129M bytes)
 pkts bytes target     prot opt in     out     source               destination         
2569K  152M neutron-vpn-agen-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2574K  152M neutron-postrouting-bottom  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2204K  130M neutron-meter-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: l3 l3-agent metering vpnaas

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

Title:
  Corrupt POSTROUTING Chain when using Metering and VPN agents together

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  I'm using the Icehouse UCA version 1:2014.1.3-0ubuntu1~cloud0 of the
  VPN(openswan driver) and Metering(iptables driver) agents on Ubuntu
  Precise.

  The ordering of the POSTROUTING chain in the NAT table inside router
  namespaces seems to be broken.  In many of my routers, the neutron-
  postrouting-bottom rule is listed before the neutron-vpn-agen-
  POSTROUTING rule.  This causes traffic that should have traversed a
  VPN to be Source NAT'd as if it were traffic leaving via the default
  route.  Rescheduling the router or removing metering rules for it seem
  to cause a re-ordering of rules.

  It seems to me that neutron-postrouting-bottom should always be the
  last rule in the POSTROUTING chain.  Is this correct?

  In the following state, VPNs are broken regardless of the existence of
  Phase 1 and Phase 2 IPsec

  Chain POSTROUTING (policy ACCEPT 2194K packets, 129M bytes)
   pkts bytes target     prot opt in     out     source               destination         
  2199K  129M neutron-meter-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  2568K  152M neutron-postrouting-bottom  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  2563K  151M neutron-vpn-agen-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0      

  Removing metering rules can cause the above chain to be changed into
  the following, which I assume (but have not verified) would break
  metering, were it enabled.

  Chain POSTROUTING (policy ACCEPT 2199K packets, 129M bytes)
   pkts bytes target     prot opt in     out     source               destination         
  2569K  152M neutron-vpn-agen-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  2574K  152M neutron-postrouting-bottom  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  2204K  130M neutron-meter-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0

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