James Yonan wrote:
On Thu, 2 Dec 2004, Piergiorgio Spagnolatti wrote:
First of all, thank you all for this great software. Openvpn amazed me
from te beginning and still does
as I keep discovering its capabilities.
And now a couple of questions. This is my current setup:
Openvpn (2.0b15) in "server mode" (multiclient). Authentication is done
(obviously) with x.509 certificates and configuration
is pushed to the clients with static routes and so on. All is working
fine. Now, I'd like to implement a sort of "dynamic firewall",
which applies iptables rules on a "per certificate" basis. I am
implementing this using the useful "--learn-address" switch with openvpn.
The idea is to get the cn of the certificate, and get the rules to be
applied from configuration files, or database, or ldap, or whatever, as soon
as the tunnel is opened and ip/routes/subnets appear..
Now, a couple of questions rise:
1 - when does the "delete" event raised from openvpn with
--learn-address occur? I tried launching the openvpn server with a
thate echoes the parameters passed by leard-address, but received mostly
"add" and "update". Just once I received the "delete" event, and can't
really reproduce the behaviour. I supposed that closing the connection
from either peer would produce a "delete" event but it doesn't. I also
supposed that some sort of timeout comes in after a while (after the
connection is closed from the client), but no "delete" even after
The delete event is raised some time after the client-instance object on
the server is deleted. This is usually a function of the keepalive
2 - --learn-address invokes my script in case of an "add", "update", or
"delete" event. In the first two cases (add/update), i receive the
operation (add or update), the ip/cidr being configured, and the cn of
the peer's certificate. In the latter case (delete) the cn is missing
(as stated also from the manpage). I want to apply iptables rules in
case of new addresses coming in, update 'em as needed
and delete 'em as soon as possible (actually, when the tunnel is closed).
If the first two cases are easy to manage, since I have the cn and can
retrieve the rules to be applied, in case of a "delete" event, I cannot
how to match the existing rules with the ip/subnet being "turned off".
So, if I get from learn addr, for example:
add 10.8.0.6 mycert.mydomain.com ---> ok, read mycert.mydomain.com rules
and apply 'em to 10.8.0.6
update 10.8.0.6 mycert.mydomain.com ---> ok, read mycert.mydomain.com
rules and apply 'em to 10.8.0.6
how could I flush/delete the rules/chains read from
"mycert.mydomain.com" configuration, since I loose the "ip - common
An idea could be to create chain names as, for example, 10_8_0_6 in this
case, and drop the chain according to the ip. Anyway, the whole idea
behind the cn
usage should be to manage firewall rules at a higher level (rules based
on the user/certificate, not on its dynamic ip).
Any suggestion would be greatly appreciated. Keep up the incredible work :-)
Right now the learn-address delete method is called late, when the address
itself is deleted from the routing table, and after the original common
name is no longer defined.
The reason for this is that OpenVPN doesn't immediately delete virtual
addresses from the routing table when the client instance is deleted.
Instead, it marks it for deletion, and it is deleted later by a sort of
garbage collection routine.
Thanx for the answe James.
Ok. In fact the "immediate deletion" of the virtual addresses (and hence
of the related iptables rules) is not that big issue,
as long as you know that the addresses are not used by someone else. I
assume that the "update" method comes in if
another peer (or even the same peer) reconnects and reuses the above
virtual ip/ips. So it is actually safe to let them on
and "clean up" as long as an "update" call arrives to the script.
The problem, anyway, remains. Since the garbage collection "loses" the
information about the common name in the certificate,
(and no problem about it with openvpn itself... since it's just another
virtual ip at this stage), scripts called from --learn-address
can't really drop (my case) iptables rules raised on a per user/per
certificate basis. This would cause (depending on the number
of peers and connections) potentially a lot of rules being left "on"...
so a sort of garbage collector would be needed for iptables too
(maybe, actually monitoring virtual ip addresses with ip/ifconfig...
sounds not elegant though...).
Is there any other way of knowing that the certificate/peer is
"disconnected", "gone" or whatever? It could be sufficient in order
to inform the above script to flush the right iptables chains/rules. Or,
could it be useful/possible to patch openvpn so that common name
is kept along with virtual ip addresses in the garbage collector? This
way, the "delete" method could serve all the information needed
for iptables cleanup.
Openvpn-users mailing list