Is transparent proxy broken in Core 167?


I have a server that has a block rule for all RED network access and should only be able to connect through the proxy. Before configuring the proxy settings on the server I wanted to test the transparent proxy.


This runs into a timeout. I ensured that the proxy actually works:

wget -e use_proxy=yes -e http_proxy=$IPFIRE_GREEN:3128
wget -e use_proxy=yes -e http_proxy=$IPFIRE_GREEN:800

Both requests were succesful, and I can see them also in the proxy logs. But why does the transparent request fail?


  • Transparent is enabled for Green And Blue
  • The request comes from Green
  • Disable internal proxy access to green is (and blue) is not checked
  • Blue and green are in the allowed subnets
  • No unrestricted or Banned IPs or MAcs


apologies for the late reply on this.

No, not that I am aware of.

Are there any correspondent firewall hits logged at the time you tried the first (direct) request?

On a general note, please keep in mind that the transparent proxy does not work for HTTPS requests (since transparent interception is precisely what HTTPS/TLS was designed to protect us from :slight_smile: ), so I guess it makes more sense to turn the transparent functionality off, and go for the vanilla proxy mode. Eventually, you will need it anyways.

Thanks, and best regards,
Peter Müller

I enabled logging for the outgoing Block and can see now an FORWARDFW entry. Shouldn’t this be a DROP instead?

Of course I tested it with HTTP. The example commands I gave were not obfuscated. httpforever seems to be an http only website.

If I disable logging for this rule I don’t see a log entry - so It must be that rule that matches.