2

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
  • Are you sure the untrusted client and/or the SRX can resolve the DNS of the redirect URL? – kars Sep 21 '17 at 14:36
  • Yes, completely. – Michał Sacharewicz Sep 21 '17 at 19:48
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Feb 21 '18 at 17:42
  • No answer did help me so far, but I am still working on this issue. – Michał Sacharewicz Mar 27 '18 at 12:19
2

The issue is: you applied a wrong profile (profile Block-Message-WLAN-profile) on your rule-sets Block-Message.

The correct profile is profile Block-Message-profile (without 'WLAN' word in betwwen) as defined.

In addition, to ensure your from-zone UNTRUSTED-CLIENTS to-zone INTRANET policy is working properly, try to access/open the URL of blockmessage.local (on BOCK-URL-SERVER) directly from your untrusted clients.

I hope it is helpful.

  • I have applied a correct profile, I've just made this mistake while pasting and anonymising the code. This wouldn't be possible anyways, because misnamed and thus undefined profile, even if allowed during edit, would pop out during commit check :) – Michał Sacharewicz Sep 19 '17 at 9:39
  • The second policy (to-zone INTRANET) works properly, I am able to access the blockmessage.local directly. – Michał Sacharewicz Sep 19 '17 at 9:40
  • @MichałSacharewicz Does it work with http pages? please give it a try with http traffic and remove ssl-encryption any – Hung Tran Sep 19 '17 at 13:51
  • I've tried it with both HTTP and HTTPS on the client side. As for redirection URL, it's HTTP, but the target server redirects client further to HTTPS on the same server. – Michał Sacharewicz Sep 19 '17 at 17:40
  • @MichałSacharewicz I meant you should try to with another simple http page in your rule-sets, do not use junos:GOOGLE with ssl-encryption any; – Hung Tran Sep 20 '17 at 8:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.