[pve-devel] Firewalling Proxmox with Shorewall

Michel Loiseleur michel at loiseleur.com
Fri Aug 17 09:43:10 CEST 2012

----- Mail original -----
> > In shorewall rules files, it has generated 3 rules:
> > Ping(ACCEPT)    $VMBR0:
> > $VMBR0_VM101:tap101i0:
> > Ping(ACCEPT)    $VMBR0_EXT:
> > $VMBR0_VM101:tap101i0:
> > Ping(ACCEPT)    $VMBR0_VM100:
> > $VMBR0_VM101:tap101i0:
> >
> > Take note that this rule has the same effects as the three above:
> > Ping(ACCEPT)    $VMBR0_VM100:tap100i0
> >          $VMBR0_VM101:tap101i0
> Why do you thing this has the same effect? Instead, this has
> completely different effect for me.
> Please can you elaborate.

Sure, I'll try. First, my facts:
(a) is the IP address of my vmbr0_vm101 & is the ipaddress of my vmbr0_vm100
(b) I wanted to test a firewall between vm100 and vm101 on the same host & bridge
This rule does not have the same effects. I was trying to say that what I wanted to do could be made with a simpler and more direct rule.
> > And this one should work for an external IP this vm:
> > Ping(ACCEPT)    $VMBR0_EXT:X.X.X.X $VMBR0_VM101:tap101i0
And that's the same for this case: If I want to filter from an external IP, this rule should be enough.

Is this more clear ?

> > What do you think about :
> > 1) Renaming variables like $VMBR0VM100 to something like
> > $VMBR_VM100
> Why do you want to drop the bridge number? Or do you just want to add
> an underscore? Like $VMBR0_VM100 - that would be OK for me.

It's just an underscore, sorry for the typo. I'll send the patch, then.

> > 2) Enhancing vm.fw syntax with a vm1XX:net0 syntax, instead of its
> > IP ?
> Using IPs is standard, so it makes no sense to remove that feature.
> The purpose is not
> to select a specific VM. You use that to limit access to/from certain
> external IPs.
> But you are right, we can allow VM zone names additionally.
> > 3) Enhancing vm.fw syntax with a brX syntax in order to get a rule
> > like
> I guess we need two different rules files. One for the VMs (this is
> implemented),
> and one per node (or cluster wide).
> The node wide rules files can have normal shorewall syntax, and we
> can allow to use
> zone variables like  $VMBR0_VM100. That file can only be edited by
> admin, so we can
> basically allow all shorewall features there (DNAT, SNAT, ...)

I agree with you, we need a node wide rules files. When I tested, gui was not accessible and I knew that my ssh won't be able to reconnect.

> > I am not sure, too, if this can work between 2 bridges.
> This will not work between different bridges, and this is intended
> behaviour.
> If someone wants that, he needs to use a routed network setup (like
> openvz venet).
> Do you think this limitation will bite us? I don't really think that
> is needed.

ATM, it's not really clear in my mind what a routed network setup can look like. But my guess is clearly "No", provided the fact that it's clear in the doc. Firewall can be deactivated easily and completely. So if one would like to implement firewall in a different software or appliance (like a FortiGate or a Checkpoint), he would be able to do that.

More information about the pve-devel mailing list