Hi, After creating openvswitch bridge, there are multiple interfaces ("ovs parts") left. To which firewalld zones they belong? (entire setup is working - I am just researching proper configuration)
ovs bridge was created via nmcli, existing interfaces (nmcli c s): br0 - ovs-bridge br0_p01 - ovs-port br0_p02 - ovs-port br0_p01_i - ovs-interface (this is the only one with IP address) ens1 - ethernet
(ip a s) shows only ens1 and br0_p01_i interfaces.
(firewall-cmd --get-active-zones) shows all of them.
The functional interface (br0_p01_i) belongs to zone with whatever its function is (internal, external, dmz, ...). All of the remaining interfaces ended up in public zone (I am guessing NM added them to "default" zone).
Can I disable all of the filtering (by firewalld) on the ovs bridge? How? Since ovs is layer 2, than in theory firewalld (which is basicly layer 3 filter) should not be involved at all. Than why assign, a non-layer 3 interfaces to a layer 3 firewall zone?
Any insights are welcomed. CentOS 8 was used for this setup.
On Tue, Sep 15, 2020 at 09:22:38AM -0000, Gal Anonim wrote:
Hi, After creating openvswitch bridge, there are multiple interfaces ("ovs parts") left. To which firewalld zones they belong? (entire setup is working - I am just researching proper configuration)
IIRC, firewalld won't see the packets on OVS ports.
ovs bridge was created via nmcli, existing interfaces (nmcli c s): br0 - ovs-bridge br0_p01 - ovs-port br0_p02 - ovs-port br0_p01_i - ovs-interface (this is the only one with IP address) ens1 - ethernet
(ip a s) shows only ens1 and br0_p01_i interfaces.
(firewall-cmd --get-active-zones) shows all of them.
The functional interface (br0_p01_i) belongs to zone with whatever its function is (internal, external, dmz, ...).
If IP traffic hits br0_p01_i and it gets routed then it should pass through firewalld (and all netfilter). However, only firewalld v0.9.0 or later support FORWARD filtering. Previous releases will simply DROP the forwarded traffic or ACCEPT depending on the zone. For example, "trusted" zone accepts all forwarded traffic.
See the option `--set-target` in man page firewall-cmd for more details.
All of the remaining interfaces ended up in public zone (I am guessing NM added them to "default" zone).
Can I disable all of the filtering (by firewalld) on the ovs bridge? How?
If it's a layer 2 bridge then firewalld won't see the packets so it won't be filtering. Unless of course kernel module br_netfilter is in use (probably not).
Since ovs is layer 2, than in theory firewalld (which is basicly layer 3 filter) should not be involved at all. Than why assign, a non-layer 3 interfaces to a layer 3 firewall zone?
Good question. I don't have an answer. NM is probably assigning them because it's hitting a generic code path. I think it's harmless.
The br0_p01_i interface is only for host <-> bridge communication. VM's have their own ports on the bridge, so any network traffic to/from any VM should never go through br0_p01_i interface - at least that is what I am expecting. At this moment the target for zone, where br0_p01_i interface is, is REJECT. And everything appears to be working...
The second part of the project is podman, and br_netfilter is loaded. Podman needs br_netfilter for intra container communication via host mapped ip/port (I really need that functionality) - I haven't found workaround to be able to unload the br_netfilter module. This part also appears to be working...
What is the relation between firewalld and br_netfilter? Can firewalld do anything about/with br_netfilter?
On Thu, Sep 17, 2020 at 01:20:04PM -0000, Gal Anonim wrote:
The br0_p01_i interface is only for host <-> bridge communication. VM's have their own ports on the bridge, so any network traffic to/from any VM should never go through br0_p01_i interface - at least that is what I am expecting. At this moment the target for zone, where br0_p01_i interface is, is REJECT. And everything appears to be working...
The second part of the project is podman, and br_netfilter is loaded. Podman needs br_netfilter for intra container communication via host mapped ip/port (I really need that functionality) - I haven't found workaround to be able to unload the br_netfilter module. This part also appears to be working...
Then the bridged packets are likely subject to firewalld's filtering. There is also an associated sysctl. 1 means send to netfilter. 0 means don not send to netfilter. This sysctl is only available if br_netfilter is loaded.
# sysctl -a |grep bridge net.bridge.bridge-nf-call-arptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1
What is the relation between firewalld and br_netfilter? Can firewalld do anything about/with br_netfilter?
br_netfilter will send _bridged_ packets to netfilter. If it's enabled, then firewalld will see _bridged_ packets in addition to _routed_ packets.
firewalld-users@lists.fedorahosted.org
-
Eric Garver -
Gal Anonim