Peter Allgeyer wrote:

>>Another note: if OpenVPN depends on the DHCP server or something else, 
>>that configuration should be tied to OpenVPN, so when one thing changes, 
>>so does the other... This goes back to my prior complaint about NAT 
>>rules not being tied to their firewall rules. If you kill a VPN server, 
>>it's DHCP and bridging rules should die also, etc.
>>    
>>
>I've looked over it the last few days and recognized that this is very
>problematic to implement. I thought of a field <inuse/> that can be
>checked if someone wants to delete an interface. Next step would be to
>have an algorithm that deletes all corresponding rulesets automatically.
>But constructing such a dependency tree is a lot of work and could lead
>us to a real patchwork. I believe it is one thing to consider for
>1.3beta, if and then we decide to go for a cleaner design.
>  
>
Actually, my idea was to add a field to each rule saying what it depends 
on. If the dependency can't be found, the rule is void, and should be 
deleted.

i.e. a firewall rule would have <depend component="NAT" ruleid="<some 
hash>" />
or even:
<depend component="NAT" ruleid="<same hash>">
    <map source="target" dest="destination" 
format="<address>%s</address>" />
    ...
</depend>

... but the second way is ugly, and probably an extremely bad idea.

Anyway, when (in this case... translates to other systems also) a NAT 
rule is deleted, it knows whether a firewall rule is mapped to it 
(because a user would have to check a box that says "Automatically 
maintain a firewall rule for this NAT mapping"), and looks for firewall 
rules pointing at it, and deletes them. If, somehow, that doesn't 
happen, and the firewall ruleset generator gets to a bad reference, it 
deletes the rule. As for how the firewall decides how to where to look 
for the NAT component... that's another story.

This is obviously not something for the 1.2beta line.