<div dir="ltr">Answering my own question for future inquirers - <br><br>After successfully testing an lxc container as a NAT gateway, I resumed testing on openvz. I remembered there was some sort of setting to enable iptables in a container, and eventually found it:<br><br># prlctl set MyCT --netfilter full<br><br>Of course, fighting with firewalld is a whole different set of problems, but with firewalld off, it works perfectly. I'll either find the magic tweak that makes firewalld allow the forwarding, or I'll live without firewalld for now.<br><br>Jake<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 20, 2022 at 2:21 PM jjs - mainphrame <<a href="mailto:jjs@mainphrame.com">jjs@mainphrame.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"><div dir="ltr">I've been on a hardware consolidation and virtualization kick, and have been converting physical hosts in the office to openvz VMs.<br><br>I have a couple of physical boxes each connecting to an internet provider, and acting as a firewall/gateway, among other things. I was able to convert these to VMs, after adding the interfaces and creating the bridges and networks, and it works as expected.<br><br>I thought it would be more efficient to use a container, and have been testing with a container connected to an internal bridge, and an external bridge. I haven't yet been able to figure out why it won't forward traffic from the internal interface to the external interface, even though it's connected to the same networks as the VM which is successfully doing so. <br><br>Is it possible to use a container for this, or am I trying to make a container do something it was designed not to do?<br><br>Jake<br><br><br></div>
</blockquote></div>