Drop any rule is not working

Dear community,

I have a problem making some drop rules working as expected.

It actually drops all protocols (i tried to telnet some random ports, and i can see my drop rule popping in the firewall log) but HTTP/HTTPS

packet blocked:

The rules are :

Basically, i've created a network group containing a bunch of forbidden IP addresses. All traffic coming from or going to those destinations must be dropped and the call must be logged in the firewall event log.

A i said, when i try to reach any of those addresses on ports 443/80, packets are not dropped.

We use a transparent proxy managed by the UTM, and the only way to really block the HTTP/HTTPS outgoing access to those IP is to create an object in the blacklist. Absolutely not manageable for hundreds of IP addresses...

Does the transparent proxy bypass the firewall rules concerning HTTP/HTTPS protocol ? It would be quite... unsecure.

How can i prevent reaching those destinations out over this 2 damn ports ?

thank you for your help

  • Hi,


    I just tested it and actually yes.

    Same behavior here. So you need to blacklist the addresses with a proxy in transparent mode.

    Or you can use Standard mode.

    But notice that clients must have specified the web filter as HTTP proxy in their browser configuration.

    The web filter will listen for client requests on port 8080.

    So that should work.

    In my case it does and the firewall log also shows it now.



  • In reply to CdkK:

    Thank you Cdkk, so i'm not totally stupid...

    But turning the web protection in standard mode is not an option for now.

    Do you know if it's a normal behavior for a transparent proxy, i'm not very familiar to them ? But it's quite surprising.

  • In reply to philippehector:

    I never said that ;-)

    So I just found this article that describes it furthermore.

    If I got it right, then any traffic over ports 80,443 and 21 in transparent mode will go through the filter.

    From the article:

    In most firewall products, Access Control Entries are used to evaluate source and destination together.   In UTM, any traffic handled by the proxies will bypass any firewall rules, so source-destination restrictions must be enforced in the proxy configuration.   This requires extra care because the proxies implement source filtering and destination filter at different stages of the filtering process.   When planning an implementation, consider that traffic can be blocked in multiple ways:

    The packet can be evaluated by the proxy, then blocked by proxy configuration.

    The packet can be ignored by the proxy, then blocked by an explicit or default-deny firewall rule.

    The packet can be ignored by the proxy, allowed by the firewall rules, but blocked if no public-to-private IP NAT rule is applicable.

  • In reply to CdkK:


    The packet can be ignored by the proxy, then blocked by an explicit or default-deny firewall rule.

    That what i first thought, so i have created a proxy bypass rule to a destination and tried to reach it. It passed and no log generated :/

    It would have ease the deal but no luck :/

  • In reply to philippehector:

    So I just tried it. And I set a host on the Transparent Mode Skiplist.

    At my first try, the behavior was the same like yours.

    But there is a checkbox below the list:

    Allow HTTP/S traffic for listed hosts/nets

    You need to uncheck this box. Otherwise the traffic will be allowed.

    With the unchecked box your traffic will not pass the firewall

    and you can see the dropped packets in the log.

  • Salut Philippe,

    Rather than firewall rules to create drops, you need DNATs - see #2 and #4 in Rulz (last updated 2019-04-17).  If you are in Transparent mode, I would expect the DNATs to take priority over the Proxy.  If you try that and it doesn't blackhole the HTTP/S request, please let us know.  I would make the two rules like the following:

    DNAT : Internal (Network) -> Any -> Blocked IP : to {}
    DNAT : Blocked IP -> Any -> External (Address) : to {}

    Cheers - Bob

  • In reply to BAlfson:

    Hi BAlfson,

    It works by creating the DNAT rules, you just have to enable the Initial Packet log to have a trace of it.

    It does the trick so i keep this solution as it's the easier one.

    Thank you for your help.