Loopback port redirect not working

[Artur Bodera]

The following does not work as expected:

RULE="Redirect service https from local.lo to local.lo options redirectport=\"80\""

The aim is to redirect requests coming on loopback from port 443->80. It does not work because vuurmuur assigns the rule to PRE-VRMR-PREROUTING chain in nat table. For this rule to work it should be placed in PRE-VRMR-OUTPUT chain, ie:

Chain PRE-VRMR-OUTPUT (1 references)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere             anywhere            tcp dpt:https redir ports 80
R

I believe there are several ways to archieve loopback redirects, but I believe it should be handled implicitly in vuurmuurlib or vuurmuur_conf.

[Victor Julien]

Rules on the local loopback are not supported at all, nor is the usage of the same network in the source and destination parts of the rule. Can you explain what you're trying to do?

Vuurmuur doesn't place any rules in the PRE-VRMR-* chains. It just creates them so rules can be placed there that are inspected before the Vuurmuur rules are.

[Artur Bodera]

There is nothing wrong in local port redirection. Vuurmuur is a frontend, so it should be transparent to the implementation layer (iptables). If iptables and/or kernel allows it, why isn't it possible to define it in Vuurmuur ?

Loopback redirection can be used for variety of tasks, like redirecting bogus connections, port traps, protocol/services debugging etc.

Cannot use same network in source and destination? this is utterly awkward. What if the host is not a real nat/bridge and is just redirecting connections to a fall-back? No way to do that either?

In the first example I was trying to make a redirection from a custom port (i.e. 3000) to a privileged local port (<1000) - this can be used for example to create a local daemon by non-root user. I've defined it manually with "iptables -add" but I have to re-add it every time I reload rules in vuurmuur - or dump vuurmur completely.

[Victor Julien]

Vuurmuur is not trying to be a frontend for every iptables option available. Vuurmuur is primary designed as a gateway firewall, so I'm not too concerned about local traffic rules. This is also why there is a default local loopback accept rule.

You can use the PRE-VRMR-* chains to add custom rules, including local rules. Vuurmuur will only create the chains, not the rules in them. It's easy to script adding the iptables rules though, so they are loaded on boot.

I'm not planning adding local lookback options, so I'm closing the ticket.

[Artur Bodera]

Ok, designer's choice, but consider documenting this (better).

Right now vuurmuur silently accepts these rules but does not add them to chains.

[Artur Bodera]

Consider "Vuurmuur is a powerful firewall manager[...]that allows both simple and complex configurations". Loopback is just an interface (on 127.0.0.0/24) and should be treated as one.

I don't see a point of implicitly disabling this functionality. As a manager (or frontend) it should really not be picky about what and how you set up, as long as it's syntactically valid - it's a tool and you cannot possibly imagine all uses of iptables that users will have. Anyways, vuurmuur_config allowed me to define all necessary rules, but the lib didn't do the job so it looks like more like a bug (logs show that vuurmuur just "skips" these rules, even though they are defined in conf)

Also: this won't work when connecting internally (lan-lan): ​http://www.vuurmuur.org/trac/wiki/TransparentProxy

Also: "fwbuilder" :)

[Victor Julien]

Well the loopback isn't very important on a gateway firewall, so that was why that choice was made this way. In all the years I've been developing and supporting Vuurmuur no-one ever came to me about it, so I guess for most it's fine this way.

That said, I'm willing to consider adding an option that disables the automatic loopback accept rule so you can cook you own rules for the loopback. I'm not sure what other changes to Vuurmuur would need to be done to properly support that, maybe you can do some research into that...

I agree that Vuurmuur shouldn't accept unsupported rules. I guess unsupported isn't the right term, it's more that the result is undefined... Feel free though to open tickets for those specific situations.