What I need

I have SRX 1400 @ JUNOS 12.3X48-D40.5

Imagine having, among others, following zones: UNTRUSTED-CLIENTS, WORLD and INTRANET.

I want to block all traffic from UNTRUSTED-CLIENTS to WORLD, but I want to keep users to know why they are being blocked, thus I want them to be redirected to custom URL (eg. http://lockmessage.local) on a machine located in INTRANET.

Attempt

I have created a simple Application Firewall profile, that should match all traffic and deny it with custom-redirect-url specified. This profile has then been attached to a permit policy.

Result

• The policy is correctly matched against traffic (as evidenced in logs)
• User cannot access any URL in WORLD zone, but…
• User does NOT reach a designated URL, getting timeouted instead 🙁
• No traffic between UNTRUSTED-USERS and INTRANET is logged

Any suggestions?

• Should this work, or am I completely wrong?
• What might be missing?
• Is there another way I can achieve what I want?

Config

Application firewall:

application-firewall {
    profile Block-Message-profile {
        block-message {
            type {
                custom-redirect-url {
                    content http://blockmessage.local;
                }
            }
        }
    }
    rule-sets Block-Message {
        rule Dummy-Policy-Deny-Everything {  # I am using any application available, since I need at least one rule;
            match {
                dynamic-application junos:GOOGLE;
                ssl-encryption any;
            }
            then {
                deny {
                    block-message;
                }
            }
        }
        default-rule {  # For all other websites - also block
            deny {
                block-message;
            }
        }
        profile Block-Message-profile;
    }
}

Afterwards, policy (ommited logging to make it tidy):

policies {
    from-zone UNTRUSTED-CLIENTS to-zone WORLD {
        policy REDIRECT-UNTRUSTED-CLIENTS-TO-BLOCK-URL {
            match {
                source-address any;
                destination-address any;
                application [ junos-http junos-https ];
            }
            then {
                permit {
                    application-services {
                        application-firewall {
                            rule-set Block-Message;
                        }
                    }
                }
            }
        }
    }
    from-zone UNTRUSTED-CLIENTS to-zone INTRANET {
        policy ALLOW-ACCESS-TO-BLOCK-URL-SERVER {
            match {
                source-address any;
                destination-address BOCK-URL-SERVER;
                application [ junos-http junos-https ];
            }
            then {
                permit 
            }
        }
    }
}

Update 1

I've pinpointed a specific behavior that might give a clue.

When monitoring the run show security application-firewall rule-set all command output, I've noticed that:

1. the number of sessions redirected is always zero, so it's not the redirection failing to work, but rather failing to trigger;
2. the number of sessions matched is stuck at some old value of 85, but does not grow anymore; this is most likely because I have limited the parent rule to application junos-http; the 85 value might mean, that in past, before limiting policy to junos-ssh, some other protocols might have matched/triggered the default rule but are no longer matching it; why?
3. the only counter that is visibly reacting to my traffic is Number of sessions with appid pending;
4. all these sessions are correctly matching the policy in question, it can be prooved with use of show security flow session application-firewall-rule-set Block-Message.

Full listing of command:

Rule-set: Block-Message
    Logical system: root-logical-system
    Profile: Block-Message-LAN-Unauthenticated-profile
    Rule: Dummy-Policy-Deny-Something
        Dynamic Application Groups: junos:web
        SSL-Encryption: no
        Action:reject or redirect
        Number of sessions matched: 0
        Number of sessions redirected: 0
Default rule:reject or redirect
        Number of sessions matched: 85
        Number of sessions redirected: 0
Number of sessions with appid pending: 4