Documentation / What it watches
Firewall
Profile state, and filters owned through the Windows Filtering Platform.
GURDN does not replace Windows Firewall. It reads the state Windows holds, and where it adds filters it adds them through the platform interface Windows provides, under an identity that marks them as GURDN's.
Profile state
GURDN observes which host firewall profile is in force and whether it is enabled, read from the local firewall policy store. With authorisation it can enable a profile, then confirm the change by reading that same store back, which is the source it reports state from.
Filters
Where supported, GURDN manages filters through the Windows Filtering Platform. Three properties matter:
- Ownership is enforced by the platform. Filters are registered under a provider that belongs to GURDN, so Windows itself distinguishes them from every other filter on the machine. GURDN will not remove a filter that is not its own, and that is a structural fact rather than a naming convention it has agreed with itself.
- Changes are transactional. A set of filters is added inside a platform transaction. Either all of them are present or none are, so an interruption part way through cannot leave a partial policy behind.
- Changes are verified. After applying, GURDN enumerates the filters back and confirms they are there. A call that returned success without a matching read back is treated as a failure.
What is not implemented
Managing the ordinary Windows Firewall rules that appear in the Windows interface needs the firewall COM API, which this build deliberately does not reach. A request for one is answered Not supported, with that reason. This is recorded in the capability matrix rather than left for a user to discover.
Why this is not a firewall interface
A firewall interface shows you the rules. GURDN reads firewall state together with the resolvers, routes and adapters around it, and puts any change it makes inside an authorised, verified, reversible lifecycle. See the response engine.