In short: create a serializable object that contains the filter specification. For simple filters, an enumeration should do just fine. Then, in your WCF service, map from this filter specification to something that the lower layers of the application understand.
NHibernate (and other object-relational mappers) are tied to database retrieval. It doesn't really make sense for your client UI to be this closely coupled to your persistence system, and by attempting to use the NHibernate filter objects you'll be using them for something they're not designed for.
Some applications I've seen have multiple layers, each with their own data types: one for the UI, one for validation logic on the UI, one for data transfer between client and service, one for the business logic in the domain at the server, and one for persistence. It might seem extreme but this means that the objects can properly reflect the needs of each particular concern.
For example, you may need to compromise your data types to get your objects to serialize across a service boundary. Using different objects here from those used in the UI and business logic layers hides any ugliness.