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
manage openflows.
Change-Id: Ic900209868acfbe3bbb56fabbbf5c4472857e412
Co-Authored-By: Ihar Hrachyshka <ihrachys@redhat.com>
Co-Authored-By: Slawek Kaplonski <skaplons@redhat.com>
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.
NeutronLibImpact
Depends-On: https://review.openstack.org/#/c/647836/
Change-Id: I3c2f28ecd18996a1cee1ae3af399166defe9da87
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
three states:
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
default cookie.
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.
Change-Id: I85d9e49c24ee7c91229b43cd329c42149637f254
Closes-bug: #1708731
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
local port.
Change-Id: Ia4f524adce2b5ee6d98d3921cfb03d56ad6d0813
Closes-bug: #1747082
The EGRESS_DIRECTION and INGRESS_DIRECTION constants live in neutron-lib
now. This patch removes them from neutron and uses lib's version of
them.
NeutronLibImpact
Change-Id: I1b81f5c3de9e6f2c0967c2db23ddb716ee7ec6b9
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.
Change-Id: Iad59096f0c9855ebfd4a0d5b447e73b443d66c1d
Closes-Bug: #1697593
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.
Closes-bug: #1626010
Change-Id: Ia05d75a01b0469a0eaa82ada67b16a9481c50f1c
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]
Change-Id: Ie55c0d0a98a2b81c237ef42a55f7ce4b129828fb
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.
Change-Id: Ic4513859364403555e13593fb34bd2e58ea6377b
Closes-Bug: #1652729
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.[1]
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.
1. Ibe9e49653b2a280ea72cb95c2da64cd94c7739da
Closes-Bug: #1668958
Closes-Bug: #1657260
Change-Id: Ie88237d3fe4807b712a7ec61eb932748c38952cc
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.
Change-Id: I642abe5a40ef303efc2206df9b2d397b0d271200
Closes-bug: 1643319
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
implementation.
Functional and unit tests to cover the bug added as well.
Co-Authored-By: Jakub Libosvar <libosvar@redhat.com>
Co-Authored-By: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Closes-Bug: #1611991
Change-Id: Idfc0e9c52e0dd08852c91c17e12edb034606a361
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 <libosvar@redhat.com>
Change-Id: I498560798983177ce7b64e1a8f32f1a157558897
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.
Change-Id: Ia9538f41dfd894ed55c1db1556b37aad09ad2ae1
Partial-Bug: #1563069
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.
Change-Id: Ia93fb925b8814210975904a453249f15f3646855
Closes-bug: #1578233
With this patch functional tests for ovs firewall with run with both
vsctl and native ovsdb interface.
Change-Id: I8339d7a43a449973641922a86836f0231d22bb8f
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.
Change-Id: Ice1c9dd349864da28806c5053e38ef86f43b7771
Partial-Bug: 1502933
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
renewals.
Change-Id: Ibc2b0fa80baf2ea8b01fa568cd1fe7a7e092e7a5
Partial-Bug: #1558658
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.
Closes-Bug: 1549370
Change-Id: Ibb5942a980ddd8f2dd7ac328e9559a80c05789bb
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.
Related-Bug: #1548547
Change-Id: Ice93abbc6e143cdbb90e7d41d1be86dc9eb05006
This firewall requires OVS 2.5+ version supporting conntrack and kernel
conntrack datapath support (kernel>=4.3). For more information, see
https://github.com/openvswitch/ovs/blob/master/FAQ.md
As part of this new entry points for current reference firewalls were
added.
Configuration:
in openvswitch_agent.ini:
- in securitygroup section set firewall_driver to openvswitch
DocImpact
Closes-bug: #1461000
Co-Authored-By: Miguel Angel Ajo Pelayo <mangelajo@redhat.com>
Co-Authored-By: Amir Sadoughi <amir.sadoughi@rackspace.com>
Change-Id: I13e5cda8b5f3a13a60b14d80e54f198f32d7a529
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.
Change-Id: Ie886dec9c0e805fa8710af8ae3cb70855fd4ad29
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.
Related-bug: #1461000
Change-Id: I6251ee264396f8dbc9b284758b96e5cdc6ac500b
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
Related-bug: #1461000
Change-Id: Ib00c99f236855e6556f43f4ffc55014c73b077bb
Ihar Hrachyshka