Vineet,
I think you could use Packet filtering plugin hook and use the [KILL]
tag at the end of the pf file .
See
http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=openvpn-plugin.h;h=56b0a701574e6913b3a714e941cdc4899dbea8e1;hb=HEAD#l316
I have never used it
Hi all,
I hate to reply to my own posting but I managed to get certificate
chains working. The trick is in setting up the stacked client
certificate in the right order. Here's what I did:
ca.crt --- server.crt
+-- sub-ca.crt --- client.crt
the server is configured with --ca ca.crt and
Thanks for your response. This seems to involve file I/O and iptables right?
File I/O seems like a performance bottleneck, no?
Vineet
On Mon, Dec 13, 2010 at 4:35 PM, chantra wrote:
> Vineet,
>
> I think you could use Packet filtering plugin hook and use the [KILL] tag
> at the end of the pf fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/12/10 18:47, Vineet Kumar wrote:
> Thanks for your response. This seems to involve file I/O and iptables
> right? File I/O seems like a performance bottleneck, no?
Maybe, if you're still using tapes and need to rewind the tape ;-)
Seriously, no
>From code inspection it seems like I need to have one PF-file/client.
So for 1000 clients connected this means 1000 files! That is the
bottleneck I am talking about. Also, in my use-case the plugin (which
spawns a separate thread) is the one who asynchronously wants to close
a socket. The importan
Vineet Kumar wrote:
> Are there ways around that : making telnet accept multiple sessions?
You could serialize your administrative requests somehow and only
ever have one entity use the admin interface.
//Peter
You mean closing the telnet session after every use so that whoever
the next guy is gets served? The only problem with that is if my
plugin happens to arrive as the second telnet client session (for
killing purposes) after, say, an interactive telnet session who came
in first. As long as that inter
Vineet Kumar wrote:
> You mean closing the telnet session after every use so that whoever
> the next guy is gets served?
No I mean creating an intermediary that will know about your use case
and provide an interface that works.
> say, an interactive telnet session
Are they a requirement in your
Sorry pl. explain the "intermediary" part. Is that supposed to solve
the single telnet server accepting multiple *concurrent* client
sessions?
The interactive session part: not a requirement but we have no way to
disallow an interactive user from telnetting when we programmatically
plan to use the
On 12/14/2010 04:22:53 PM, Vineet Kumar wrote:
> Sorry pl. explain the "intermediary" part. Is that supposed to solve
> the single telnet server accepting multiple *concurrent* client
> sessions?
Yes. The multiple concurrent client sessions talk to a single
telnet server via an intermediary. Th
Cool, thanks for the clarifications. Will investigate into it.
Vineet
On Tue, Dec 14, 2010 at 2:45 PM, Karl O. Pinc wrote:
> On 12/14/2010 04:22:53 PM, Vineet Kumar wrote:
>> Sorry pl. explain the "intermediary" part. Is that supposed to solve
>> the single telnet server accepting multiple *concu
Hi,
Is there a straightforward way to print source IP address and port
given a 'struct context' pointer?
Vineet
12 matches
Mail list logo
