Perhaps I'm wrong, but I think you're looking for "next-header" for your protocol match.
term T1 { from { next-header tcp; destination-port ssh; } then { count T1; accept; } } ~Adam On Mon, Mar 5, 2012 at 9:44 AM, Justin M. Streiner <strei...@cluebyfour.org>wrote: > On Sun, 4 Mar 2012, Richard A Steenbergen wrote: > > Depends on your definition of "normal". I run into firewall bugs like >> this all the time these days (probably on my 6th one in the last 2 >> years). When in doubt, remove the filter and re-apply, this causes a >> data structure rebuild on the hw and makes the badness go away. And just >> consider yourself lucky that it doesn't cause the FPCs to crash when you >> reorder firewall terms like on EX8200 running 11.1R5. :) >> > > The only obnoxious firewall filter issue I've run into lately is that > inet6 firewall filters in Junos 10.3 don't support "protocol" as one of > their allowable match criteria. Makes it tough to write ingress and egress > filters for catching some of the 'low hanging fruit' nonsense. I hace a > case open with JTAC, but I haven't gotten a good answer yet if that's a > feature, a bug, or something that's just missing from the v6 capabilities > in that release. I didn't see anything that looked like a good match in a > cursory review of the bug list. I have a router in my lab running 10.4, so > I'll check if the same situation exists there. > > jms > > ______________________________**_________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp