Default value for "of_interface" config option was switched
to "native" in Pike release.
In the same release this option was deprecated to removal.
Now it's time to remove it and force use of "native" driver to
Co-Authored-By: Ihar Hrachyshka <email@example.com>
Co-Authored-By: Slawek Kaplonski <firstname.lastname@example.org>
All of the externally consumed variables from neutron.common.constants
now live in neutron-lib. This patch removes neutron.common.constants
and switches all uses over to lib.
Previously, when security group was updated for given port, the firewall
removed all flows related to the port and added new rules. That
introduced a time window where there were no rules for the port.
This patch adds a new mechanism using cookie that can be described in
1) Create new openflow rules with non-default cookie that is considered
an updated cookie. All newly generated flows will be added with the next
cookie and all existing rules with default cookie are rewritten with the
2) Delete all rules for given port with the old default cookie. This
will leave the newly added rules in place.
3) Update the newly added flows with update cookie back to the default
cookie in order to avoid such flows being cleaned on the next restart of
ovs agent, as it fetches for stale flows.
In case where Neutron logical port is placed directly to hypervisor,
hypervisor does a conntrack lookup before packets reach OVS integration
bridge. This patch introduces a rule with high priority that is placed
at the beginning of the egress pipeline. This rule removes conntrack
information from all packets if conntrack information is present. Then
packets continue in the egress pipeline.
That means all packets in egress pipeline are not tracked and ovs
firewall can do a lookup in correct zone. As for ingress pipeline, it
distinguishes between tracked - which are packets coming from egress
pipeline, and not tracked, which are inbound packets coming not from a
The EGRESS_DIRECTION and INGRESS_DIRECTION constants live in neutron-lib
now. This patch removes them from neutron and uses lib's version of
Current ovsfw implementation does not take care of the different
MACs in allowed_address_pairs with the VM's MAC.
This patch use the following method to fix this issue:
1. Do not check dl_src in table=72 because table=71 has checked
dl_src for Egress.
2. Add all allowed MACs in table=0 and table=73 for Ingress.
3. Do not check dl_dst in table=82 because this check has done
in table=0 and table=73.
4. Delete allowed MACs in table=0 and table=73 when needed.
The patch relies on the fact that traffic not going from instance
(and thus port not managed by firewall) is tagged. Traffic coming from
the instance is not tagged and thus net register is used for marking
such traffic. These two approaches make matching rules unique even if
two ports from different networks share its' mac addressess.
Traffic coming from trusted ports is marked with network in registry
so firewall can decide later to which network traffic belongs.
In python3, calling range() doesn't produce a list, but an iterable. We
need to explicitly convert it to a list, otherwise we get an error:
MismatchError: range(5, 16) != [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
A CIDR IP address in allowed address pairs causing init
and update operation failures on OFPort.
This is because those operations are not handling CIDR IP addresses.
This patch fixes that problem.
The regular IPTablesFirewall needs zones to support safely
clearly conntrack entries.
In order to support the single bridge use case, the conntrack
manager had to be refactored slightly to allow zones to be
either unique to ports or unique to networks.
Since all ports in a network share a bridge in the IPTablesDriver
use case, a zone per port cannot be used since there is no way
to distinguish which zone traffic should be checked against when
traffic enters the bridge from outside the system.
A zone per network is adequate for the single bridge per network
solution since it implicitly does not suffer from the double-bridge
cross in a single network that led to per port usage in OVS.
This had to adjust the functional firewall tests to use the correct
bridge name now that it's relevant in the non hybrid IPTables case.
Previously, we generated set of usable VLAN tags in the range <0; 4095>.
0 can be match with OpenFlow rules for empty VLAN tag header and 4095
fails to be added to VLAN interface with RTNETLINK error.
In several cases port masking algorithm borrowed
from networking_ovs_dpdk didn't behave correctly.
This caused non-restricted ports to be open due to
wrong tp_src field value in resulting ovs rules.
This was fixed by alternative port masking
Functional and unit tests to cover the bug added as well.
Co-Authored-By: Jakub Libosvar <email@example.com>
Co-Authored-By: IWAMOTO Toshihiro <firstname.lastname@example.org>
This patch introduces the TrunkManager for the OVS
agent. This class is responsible for wiring the trunk
and the subports.
Partially-implements: blueprint vlan-aware-vms
Co-Authored-By: Jakub Libosvar <email@example.com>
Refactoring neutron security grp config opts to be in
neutron/conf/agent so that all the configuration options
reside in a centralized location. This simplifies the
process of looking up the config opts and provides an
easy way to import.
A bunch of functional tests fail because of non implemented
x !=  operation in idlutils.condition_match() and
wrong condition passed to db_find() in OVSFW test.
This patch addresses the issue by implementing lists
comparison in native.idlutils and fixing the call to
db_find() in OVSFW test.
A functional test for OVSDB API's db_find() has been
added to ensure that querying a list column gives the same
result both with vsctl and native ovsdb_interface; unit
test for idlutils.condition_match() with corner cases has
been added as well.
IPv6 includes the concept of link-local addresses. There are address
within the fe80::/64 prefix which are used only within the local layer 2
network. They should never be routed. DHCPv6 is one of several protocols
which utilize link-local addresses.
Previously the blanket permit DHCPv6 rule permitted DHCPv6 requests from
a link-local source, before the source address was validated.
The structure of the IPtables egress firewall is:
a. fixed rules for special traffic
b. validate source address
c. fixed rules necessary for host to function
d. user rules defined by security groups
This change restricts the special traffic permitted in part (a) to only
that traffic which utilizes the "unspecified address" (::), by moving
the fixed permit ICMPv6 and DHCPv6 rules to part (c), so they are
applied after the source address has been validated. In order to enable
DHCPv6 and other protocols utilizing link-local addresses, the
link-local address corresponding to each MAC address are included in the
permitted source addresses. After the source address is verified, the
fixed rules permit ICMPv6 and DHCPv6, then the user defined security
group rules are applied.
In the existing implementation ICMPv6 and DHCPv6 rules in the fixed
ip6tables firewall rules are too permissive: they permit ICMPv6 and
DHCPv6 traffic, regardless of source MAC or IPv6 address. These rules
where intended to allow a host to acquire an IPv6 address, but
inadvertently allowed a malicious or compromised host to spoof another's
MAC or IPv6 address.
A host acquiring an IPv6 address should preform DAD (duplicate address
detection). To preform this the host must join the multicast group
corresponding to the tentative IPv6 address and the all nodes multicast
group. To join these groups the host sends ICMP MLD (multicast listener
discovery) report messages before it has an IPv6 address assigned, so
the unspecified address is used as the source address. To complete DAD,
ICMP neighbor solicitation messages are sent to solicit if any nodes
using that address. This should be the only use of the unspecified IPv6
address as a source address. The IPv4 case is similar the unspecified
address is used for DHCP discovery and request messages.
To summarize, this patch permits only ICMPv6 traffic from the unspecified
address which is used for duplicate address detection. Then it enforces
the source IPv6 and MAC addresses and finally, allows only ICMPv6 traffic
which has passed this source address validation.
In addition this patch permits traffic from all link-local addresses
associated with each MAC address assigned to the port. This is required
by many IPv6 protocols, such as DHCPv6, which depend on the link-local
addresses. This traffic was previously allowed by the blanket allow
ICMPv6 and allow DHCPv6 rules before the source address was validated.
Finally, it includes a functional test for IPv6 spoofing using both
ICMPv6 and DHCPv6 traffic. OVSFirewall currently permits this spoofed
DHCPv6 traffic. I'm excluding the OVSFirewall implementation from test
so it can be fixed in a follow on patch.
The DHCP rules in the fixed iptables firewall rules were too permissive.
They permitted any UDP traffic with a source port of 68 and destination
port of 67. Care must be taken since these rules return before the IP
spoofing prevention rules. This patch splits the fixed DHCP rules into
two, one for the discovery and request messages which take place before
the instance has bound an IP address and a second to permit DHCP
This patch makes sure that existing connection breaks once security
group rule that allowed such connection is removed. Due to correctly
track connections on the same hypervisor, zones were changed from
per-port to per-network (based on port's vlan tag). This information is
now stored in register 6. Also there was added a test for RELATED
connections to avoid marking such connection as invalid by REPLY rules.
More info in bug report. I suggest we first revert, then
re-introduce the collect_debug_info patch with a different
approach. I suspect the fix is not trivial if indeed ordering
is an issue and the namespaces are cleaned up before
collect_debug_info is fired.
This firewall requires OVS 2.5+ version supporting conntrack and kernel
conntrack datapath support (kernel>=4.3). For more information, see
As part of this new entry points for current reference firewalls were
- in securitygroup section set firewall_driver to openvswitch
Co-Authored-By: Miguel Angel Ajo Pelayo <firstname.lastname@example.org>
Co-Authored-By: Amir Sadoughi <email@example.com>
Whenever instance of ConnectionTester raises ConnectionTesterException
then custom info is collected and printed into debug log. This is useful
for debugging non-deterministic gate failures.
This tests that firewall still does its purpose even when rules are
being updated. That means there is no short period of time where
security groups are inactive during update.
Part of this patch introduces Pinger class. This object provides
capability of sending ICMP packets asynchronously and after
it's stopped it provides statistics like how many packets were
sent and how many were received. Note the difference between
assert_ping() functions, which are synchronous.
Another testing of remote security groups is also added.
Part of this patch is also preparation for having common test plan for
firewall driver testing.
Following test cases were implemented:
- dhcp works by default
- dhcp server is prevented on vm by default
- ip spoofing from vm
- allowed address pairs allows traffic to given ip
- arp can go through
- ingress/egress traffic with src/dest port ranges