Add an item to the instructions on iptables to OVS
firewall migration that the admin should cleanup
any stale iptables rules after completion. It is
out of scope of our documents on how exactly an
adminstrator might do that.
Closes-bug: #1864374
Change-Id: Ie1bf6b82e57a00f61640a131a29d897a9cde4629
Noticed a typo while reading the docs, fixed other grammatical
issues while I was here.
Trivial-fix
Change-Id: I9d62281e095688bcbcb1fbab3d1cd5101ae7ad37
Table 59 will be used for pps limitation, the pipeline change is:
all original flows with ``goto table 60`` will be changed to
``goto table 59``, while table 59 has a default rule is goto
table 60. Then we can add pps flows to table 59 for all ports.
Basic limit pipeline is:
Ingress: packets get into br-int table 0, before send to table 60,
in table 59, check the destanation MAC and local_vlan ID, if the
dest is resident in this host, do the meter pps action and send
to table 60.
Egress: match src MAC and in_port, before send to table 60,
in table 59, do the meter pps action and send to table 60.
Why table 59? Because for ovs-agent flow structure, all packets
will be send to table 60 to do next actions such as security group.
Between table 0 and table 60, there are tables for ARP poison/spoofing
prevention rules and MAC spoof filtering. We want similar security
checks to take effect first, so it can drop packets before filling
our limit queues (pps limitation based on data forwarding queue).
And we do not want packets go through the long march of security group
flows, in case of performance side effect when there are large amount
of packets try to send, so limit it before goto security group flows.
Partially-Implements: bp/packet-rate-limit
Related-Bug: #1938966
Related-Bug: #1912460
Change-Id: I943f610c3b6bcf05e2e752ca3b57981f523f88a8
Before that patch it was possible to send ICMPv6 packets like e.g.
neutron_lib.constants.ICMPV6_TYPE_MLD_QUERY,
neutron_lib.constants.ICMPV6_TYPE_RS,
neutron_lib.constants.ICMPV6_TYPE_NS,
neutron_lib.constants.ICMPV6_TYPE_NA
And that could cause some security issues as instance could advertise
that it owns IPv6 address which really don't belong to it.
Now rules in table=71 which allows that traffic are "per mac/ipaddress"
and are allowed only for fixed ips allocated to port and port's
allowed_address_pairs.
Closes-Bug: #1902917
Change-Id: I4749fdc6a6cabd253b971bf4010ff76f5593c59c
Tell something about the config option ``explicitly_egress_direct``
since there is something not so much clear for users now.
Change-Id: I1c046d8140f93d9a8cd9e0bc43d3494e4f6a1ce7
This reverts commit b8be1a05fa.
As was reported in bug [1] this patch broke multicast traffic send
from ports with disabled port security. And that broke L3HA routers
as keepalived processes couldn't talk to each other.
During attempt to fix that issue with keepalived we found out another
corner cases which we may break and in fact to fix them, we would
effectively revert this change and allow multicast traffic for all
ports in e.g. networks with ports which have port security and ports
which don't have port security and are on same node.
As we also don't really know what other corner cases we may hit going
further with that, lets revert this patch.
As a follow up patch I will propose new patch which will document
differences in handling multicast traffic between iptables and
openvswitch based firewall drivers.
[1] https://bugs.launchpad.net/neutron/+bug/1899967
Change-Id: I37a8b33cf8e16d5bb5dc1966fc2dca6bb619026c
Closes-Bug: #1899967
By default, if any multicast traffic sent to 224.0.0.X is allowed
in the OVS firewall (that means there is a specific egress rule),
this traffic is sent, in table 73 (ACCEPT_OR_INGRESS_TABLE), to
a rule with action NORMAL.
As commented in the related bug, https://tools.ietf.org/html/rfc4541,
chapter 2.1.2, section (2):
"Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports."
That means those packets will be forwarded to all ports regardless of
any ingress rule. This patch process this traffic separately, sending
those packets to table 102 (MCAST_RULES_INGRESS_TABLE). In this table
the ingress rules that have a defined protocol, will have an Open Flow
rule to output the traffic directly to those ports associated to this
rule.
For example, in the problem reported in the related bug, the VRRP
protocol (112), will be sent only to those ports that have this
ingress rule.
Change-Id: Ie271de144f78e364d938731ec9f5297e1a9d73f9
Closes-Bug: #1889631
For vlan type network, we add a segment match flow
to the openflow security group ingress table. Then
the packets will be recorded in conntrack table, and
the reply packets can be processed properly.
Change-Id: Ieded0654d0ad16235ec923b822dcd842bd7735e5
Closes-Bug: #1831534
* explain 'ingress' and 'egress'
* reword a few explanations
* provide table numbers as well as table names
* capitalize protocol names: IP, ARP, TPC, etc.
* reword explanations for tables acting as integration
points with L2 other extensions
* nits
This change also includes a newline removal in the related portion
of the code; this newline separates constants that are in fact related,
and its removal had been agreed upon to be handle as a follow-up
change to I60d299275effd9ef35c8007773d3c9fcabfa50fa.
Change-Id: Ied215b8942bfffa1f2af2f569d0e4a110a64a364
This change is a follow-up to Ib6ced838a7ec6d5c459a8475318556001c31bdf,
reintroducing a single place for applying the NORMAL action to
egress traffic, which is necessary to fix a regression introduced
by Ib6ced838a7ec6d5c459a8475318556001c31bdf.
Change-Id: I60d299275effd9ef35c8007773d3c9fcabfa50fa
Partial-Bug: 1789878
The last two items are already done.
- fullstack tests implemented in commit ff9c6e21
- updates using bundle operation implemented in commit b3b2df14
Change-Id: I2d81fde185cee04681acb9e5f156195a035cce5c
Currently, we cannot get ACCEPT packet log because there are some
changed related to ovs firewall code since ovs firewall logging has
been merged.
Regarding to performance perspective, we only log first accepted packet.
So we only need to forward first accepted packet of each connection
session to table 91 and table 92.
So this patch fixes these issues.
Closes-Bug: #1782576
Change-Id: Ib6ced838a7ec6d5c459a8475318556001c31bdf0
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 patch creates tables where other services using openflow can
implement rules for further packet processing. 3 new tables were created
for packets accepted by egress, ingress pipeline and packets dropped by
firewall.
Partially-implements: blueprint security-group-logging
Related-Bug: #1468366
Change-Id: I7900126de235ee9df902bef9556879f586d33ae8
The OpenFlow spec says packets shouldn't match against multiple flows
at the same priority or the result is undefined. In ovsfw, 8 priority
levels are needed to comply with this rule.
Note: unlike overlapping TCP port ranges cases, the current version
of OVS seems to handle this case magically.
Change-Id: I6deaee8dbe81453285b1fc685282952bc9456949
Closes-bug: #1708092
The ovsfw code generated multiple flows with the same or overlapping
match fields and different actions=conjunction(nnn,2/2) flows.
Merge such flows and generate only one flow with
actions=conjunction(mmm,2/2),conjunction(nnn,2/2) so that filtering
are correctly performed.
Change-Id: I0cd325b02f35e103606595b8b124010fff8dc397
Partial-bug: #1708092
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
Brian Haley