[j-nsp] Meaning of "except" in firewall filters

[Kevin Oberman]

> From: Tore Anderson <tore at linpro.no>
> Date: Wed, 29 Oct 2008 23:24:36 +0100
> Sender: juniper-nsp-bounces at puck.nether.net
> 
> Hi,
> 
> I'm trying to restrict SSH access on some of my routers to allow 
> connections from just a few known source networks (defined in a prefix 
> list called "ssh-allowed").  I then came up with the following, and 
> applied it as an input filter on lo0.0:
> 
> [edit firewall filter lo0-input]
> term restrict-ssh {
>     from {
>         source-prefix-list {
>             ssh-allowed except;
>         }
>         protocol tcp;
>         destination-port ssh;
>     }
>     then {
>         syslog;
>         reject;
>     }
> }
> term fallthrough {
>     then accept;
> }
> 
> This didn't work as expected, SSH connections was still allowed from any 
> host (both from inside networks found inside ssh-allowed as well as from 
> outside).  It seems like the restrict-ssh term never matched.
> 
> If I removed the "except", it worked as I would have thought - 
> connections from hosts inside prefixes found in the ssh-allowed prefix 
> list was denied, while connections from the rest of the internet was 
> allowed.  Of course, this is the opposite behaviour of what I want.
> 
> I can work around it by making first a term that accepts SSH from the 
> known prefixes, then another term that rejects all other SSH 
> connections, and finally the fallthrough that accepts the rest.  However 
> this behaviour made me really curious...  Isn't "except" supposed to 
> invert the logic of the match?  That's how I understand the help text, 
> at least:
> 
>     except               Match addresses not in this prefix list
> 
> It doesn't seem to work that way, though.  Does anyone know how it's 
> supposed to be used?

I don't normally see 'except' used quite like this.

Why not just do the boolean inverse:

filter router-inet.0-access {
    term ssh-accept {
        from {
            source-prefix-list {
                management-access;
                other-access;
                vendor-debug-access;
            }
            destination-port ssh;
        }
        then accept;
    }
    term ssh-reject {
        from {
            destination-port ssh;
        }
        then {
            log;
            reject tcp-reset;
        }
    }
[...]

This is just the ssh snippet from the much longer filter we put on lo0,
but I don't see a reason not to do it this way.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20081030/b5907fbb/attachment.bin>