[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] "dynamic iptables" and learn-addr, how???

  • Subject: Re: [Openvpn-users] "dynamic iptables" and learn-addr, how???
  • From: Piergiorgio Spagnolatti <piergiorgio.spagnolatti@xxxxxxxx>
  • Date: Thu, 02 Dec 2004 18:29:11 +0100

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 simple command
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 several minutes.

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 parameter.

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 figure out
how to match the existing rules with the ip/subnet being "turned off".

So, if I get from learn addr, for example:

add mycert.mydomain.com ---> ok, read mycert.mydomain.com rules and apply 'em to
update mycert.mydomain.com ---> ok, read mycert.mydomain.com rules and apply 'em to

how could I flush/delete the rules/chains read from "mycert.mydomain.com" configuration, since I loose the "ip - common name" binding?

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.

Thanx again

Openvpn-users mailing list