<div dir="ltr">Laine, <div><br></div><div>Though I can't remember the particulars, I have a vague memory of the sysctl settings in that article indeed solving the problem of traffic not being forwarded on the bridge when I had configured no filtering on the guest - hence my attempt to share what worked for me. Perhaps it would be good to update that page. I looked around for a link to create an account on the libvirt wiki but could find none. I'm happy to go do some more research around the items you mentioned and add a quick note to that page to keep from leading people astray in the future, if I could get an account on the wiki. Do you know how I would do that?</div><div><br></div><div>Thanks, </div><div>Tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 14, 2022 at 8:12 AM Laine Stump <<a href="mailto:laine@redhat.com">laine@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> On 2/13/22 5:38 PM, Tom Ammon wrote:<br> > Can you post the output of iptables -L?<br> > <br> > By default, the bridge module in the kernel sends packets traversing the <br> > bridge to iptables (in the FORWARD chain I believe) for processing. So <br> > if you have configured a DENY policy on the FORWARD chain, or are <br> > otherwise filtering in the forward chain, you'll be affecting packets <br> > traversing the bridge. Check out this page for details on how to change <br> > this behavior: <br> > <a href="https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf" rel="noreferrer" target="_blank">https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf</a> <br> > <<a href="https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf" rel="noreferrer" target="_blank">https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf</a>><br> <br> That information is *very* out of date; the situation has changed quite <br> a lot since that was written in 2014.<br> <br> Filtering of packets traversing a bridge device are now only filtered if <br> the br_netfilter module is loaded, which isn't done by default. It *is* <br> autoloaded if certain types of iptables rules are added(I can't remember <br> the details of the type of rule though - there was a bug in iptables a <br> year or so ago where autoload of br_netfilter was triggered by libvirt <br> attempting to *remove* a rule of whatever type it was).<br> <br> Anyway, unless "lsmod | grep br_netfilter" shows that you have <br> br_netfilter loaded, this entire path is a red herring (if you do have <br> it loaded, unload it, and try to figure out why it was loaded).<br> <br> (Interestingly, this is the 2nd time this particular outdated page has <br> come up in the last week. Has something else broken somewhere that's <br> causing people to search out this page?)<br> <br> > <br> > Tom<br> > <br> > On Sun, Feb 13, 2022 at 4:08 PM Marcin Groszek <<a href="mailto:marcin@voipplus.net" target="_blank">marcin@voipplus.net</a> <br> > <mailto:<a href="mailto:marcin@voipplus.net" target="_blank">marcin@voipplus.net</a>>> wrote:<br> > <br> > I have been struggling with this for weeks and I was unable to find an<br> > answer on line. Perhaps someone here can help me.<br> > <br> > Oracle linux 8 running virtualization:<br> > <br> > hardware node has a public IP address on interface bridge0 and physical<br> > eno1 is a member of the bridge0<br> > <br> > a virtual OS has interface bridged to lan and source is bridge0, Ip<br> > address of virtual OS is also a public from same class as the<br> > hardware node.<br> > <br> > I can route in and out of virtual, I can ping from hardware node to<br> > virtual and vice versa, so the routing works as it should, sort of.<br> > <br> > When I try tracepath or traceroute from outside to virtual I get !H on<br> > last hup<br> > <br> > same result when I try to do the same form hardware node to virtual<br> > I get !H<br> > <br> > Also, when I telnet (TCP) to a specific port on virtual where I have a<br> > daemon LISTENING OR NOT I get: No route to host. Same experiment works<br> > just fine for ssh port.<br> > <br> > Firewalld is not running, and I just have very basic iptables rules<br> > like<br> > allowing external address block to ssh to hardware node and to virtual<br> > dropping connections from all other sources<br> > <br> > This issue presented it self when I attempted to setup a galera node on<br> > virtual and ports 4567 is responding but 4568 and 4444 are not, but the<br> > daemons are running and I can clearly see lsoft showing "LISTENING"<br> > <br> > I capture the traffic and the tcp as well as udp are getting to the<br> > virtual. Is there a preconfigured netfiltering that I am not aware of?<br> > <br> > What am I missing?<br> > <br> > <br> > <br> > <br> > -- <br> > Best Regards:<br> > Marcin Groszek<br> > Business Voip Resource.<br> > <a href="http://www.voipplus.net" rel="noreferrer" target="_blank">http://www.voipplus.net</a> <<a href="http://www.voipplus.net" rel="noreferrer" target="_blank">http://www.voipplus.net</a>><br> > <br> > <br> > <br> > -- <br> > -----------------------------------------------------------------------------<br> > Tom Ammon<br> > M: (737) 400-9042<br> > <a href="mailto:thomasammon@gmail.com" target="_blank">thomasammon@gmail.com</a> <mailto:<a href="mailto:thomasammon@gmail.com" target="_blank">thomasammon@gmail.com</a>><br> > -----------------------------------------------------------------------------<br> <br> </blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">-----------------------------------------------------------------------------<br>Tom Ammon<br>M: (737) 400-9042<br><a href="mailto:thomasammon@gmail.com" target="_blank">thomasammon@gmail.com</a><br>-----------------------------------------------------------------------------</div></div></div></div>