[j-nsp] port-except filter term behaviour problem.

[Scott A. McIntyre]

Hello,

This may well be a case of "What am I missing that's obvious" but I seem to
bump into firewall/filter oddness on JunOS every now and again, so, who
knows.

On an interface I have a input filter which looks as such:

term protect-webserver-tcp {
    from {          
        destination-address {
            5.6.7.8/32;
        }           
        protocol tcp;
        port-except 80;
    }               
    then {          
        count discard-webserver-tcp;
        discard;    
    }               
} 


We had a complaint from one specific source (1.2.3.4) that they could not
not reach port 80 on 5.6.7.8.  Others have been able to reach it without
incident.  I inserted the following term above the protect-webserver-tcp
term:

from {
    source-address {
        1.2.3.4/32;
    }
}
then {
    log;
    discard;
}


And that indeed generated:

Time of Log: 2005-04-21 18:47:30 CEST, Filter: pfe, Filter action: discard,
Name of interface: ge-2/2/0.0
Name of protocol: TCP, Packet Length: 48, Source address: 1.2.3.4:2350,
Destination address: 5.6.7.8:80

But (and it's a big but): The connection established without problem.

The last term in the input filter is an accept, but clearly the discard was
first.

With the protection filter changed to two filters, one for permitting port
80 and one for discarding everything, the situation also works.

So, what am I missing here?  Have I mis-understood the use of the
port-except expression?  

"+ port-except          Do not match TCP/UDP source or destination port"

I took that to mean "other than the port listed, perform this term" which
would have discarded all traffic that was not 80/tcp, but permitted that.

What is most boggling is that the explicit discard as the first rule in my
input filter somehow changed the state of the firewalling such that later
terms were still evaluated and accepted.

>From the apache logs:

1.2.3.4 - - [21/Apr/2005:18:47:37 +0200] hostname "-" 408 - "-" "-"

(The delay of 7 seconds is accounted for by various internal processes).

Illumination appreciated, as always.

Regards,

Scott A. McIntyre