Hi,
Not having too much programming knowledge about openSSL, I wonder why
each VPN config must specify TLS-client or TLS-server. If full-mesh
bridging/routing will be supported in the future, most nodes are just
peers, without a client-server relationship.
Just wondering,
Cheers,
Rolf
nections seem tu survive
much longer!
Hope this is useful information.
Cheers,
Rolf Fokkens
Apr 1 03:23:32 plaza-server openvpn[2502]: TLS: Initial packet from
83.118.84.1
29:11800, sid=737dedce 3fab1f1c
Apr 1 03:23:33 plaza-server openvpn[2502]: VERIFY OK: depth=1,
/C=NL/L=Groningen/O=Vertis
Hans Wolff wrote:
I'm sure you'll hear complaints, but this question probably belongs in
openvpn-users.
Anyhow, can you post your configs for both ends?
You may be right, but I have the impression it may be a bug, which is
more a developer issue.
I'll post both configs in a subsequent em
Hi!
When not running as a daemon (--daemon option), OpenVPN writes all
output to stderr. When OpenVPN isn't run interactively, but it actually
isn't run with the --daemon option as well, it's rather inconvenient
that syslog isn't used. This is primarily an issue for the development
of a VPN a
James Yonan wrote:
Rolf,
A patch very similar to this one was already added in 2.0.1-rc1:
Thanks, then I'll wait for 2.0.1 to become final.
Hi,
I created an OpenVPN admin interface, which I want to show the actual
connected server of a client. The normal "state" command in the admin
interface does not provide the information. The attached patch adds an
extra argument to the "state" result which shows the server's IP. Like this:
Hi,
Using OpenVPN to build a WAN, I noticed a disturbing thing: After
failing over to secondary OpenVPN server it takes a long time until a
ping to a client side IP works again. I think I know what's happening:
An OpenVPN server learns client-side MAC addresses based on the source
MAC addres
Hi,
Using OpenVPN to build a WAN, I noticed a disturbing thing: After
failing over to secondary OpenVPN server it takes a long time until a
ping to a client side IP works again. I think I know what's happening:
An OpenVPN server learns client-side MAC addresses based on the source
MAC addresses
Marcelo Toledo wrote:
great to read it! We're going to test your patch. Thanks a lot.
Wonderful, beware however there's another issue te be resolved: MAC
aging. Switches require their mac-table te be refreshed regularly,
otherwise the MAC entries are aged out (on cisco in 300 sec). OpenVPN
Marcelo Toledo wrote:
Em Ter, 2005-10-04 às 14:06 +0200, Rolf Fokkens escreveu:
So another thing that should be implemented probably is aging.
Alright, I am aware. Are you planning working on this?
Attached you'll find find a new patch which includes aging. Could you try?
Marcelo Toledo wrote:
We have tested it in two ways:
1. Applied only in the server, worked perfectly with 3 clients. Right
now we're going to try few hundreds.
2. Applied the patch only in the client, worked well but they couldn't
see each other.
Should I apply in both or only in the server i
Marcelo Toledo wrote:
Em Sex, 2005-10-07 às 18:19 +0200, Rolf Fokkens escreveu:
Could be a silly question, but to be sure: you had the client-to-client
option enabled on the server side?
Yes we do.
The patch should work both on the client and the server, but for clients
it
Marcelo Toledo wrote:
In the main server we installed the patch. We have ~400 clients
connected to it, 3 of them we also installed the patch, here is the
result.
All these 3 clients couldn't see each other but they could see the
remaining 397 clients. The 397 couldn't see the 3 clients.
I thin
Rolf Fokkens wrote:
The problem is caused by the fact that the MAC table only keeps track
of MAC's behind clients, no MAC's behind the TAP interface are
registered. This can easily be fixed by registering them as well. I'll
get back on that as well.
Well, another patch. It
James Yonan wrote:
Why don't you use the existing multi_context::vhash hash to keep track of
the server-side MAC table? I know that this hash is usually used to
associate MAC or IP addresses with a given client instance, but it seems
ideally suited for this. Maybe you could add a flag to struc
Rolf Fokkens wrote:
James Yonan wrote:
Also, it would be great if you could #ifdef this code so that we can turn
it on or off.
Sure, I'll do that. I'll do it based on mac_table.[ch], to save time.
OK? If you want we can integrate mac_table functionality into
lists.[ch],
Marcelo Toledo wrote:
Sat Oct 8 14:28:25 2005 Data Channel MTU parms [ L:1576 D:1450 EF:44
EB:135 ET:32 EL:0 AF:3/1 ]
Sat Oct 8 14:28:25 2005 Listening for incoming TCP connection on
[undef]:1194
Sat Oct 8 14:28:25 2005 TCPv4_SERVER link local (bound): [undef]:1194
Sat Oct 8 14:28:25 2005 TC
Hi,
Attached the latest version of the MAC table patch. This patch allowes
OpenVPN to learn (and importantly forget!) MAC addresses like ethernet
switches. Also (like ethernet switches), OpenVPN now broadcasts packets
with unknown MAC addresses (without the patch these packets are dropped).
We're considering to use shorter-lived client certificates for our VPN
users. In an effort to prevent negative impact for our staff due to
expired certificates, we 'd like to keep track of imminent expiration
of certificates in the client-connect script (which we're using anyway
to check is the cer
On Fri, 2019-08-16 at 13:45 +0200, David Sommerseth wrote:
> This gets a Feature-ACK from me. This is useful information, and
> something
> other users in the community have asked for earlier too. But there
> are a few
> things here before starting to dive into the details.
>
> First of all, we
20 matches
Mail list logo
