As currently written, openvpn appears to be unable to detect the partial
failure (unidirectional) of a UDP based tunnel.
Attached is a note I sent to i...@openvpn.net about this yesterday,
figured I'd mention progress on the devel list as well.
Basic summary, assume bridged link from A <-> B, and a unidirectional
failure, openvpn configured with keepalives:
A ------> B
A: sends pings, never gets any traffic or ping packets, constantly
restarts/exits
B: sends pings (they never actually make it to A), but sees pings
from A, thinks everything is fine.
I've written some code to implement a ping request/reply facility -
however, here's where I'm hitting up against a secondary snag. It looks
like in the code right now, there isn't really any way to cleanly
request a packet be sent. encrypt_sign() sortof appears to do this, but,
with how it (and the other code is implemented), it appears to only
permit a SINGLE packet to be generated by ANY of the various tasks
spawned off in the event loop.
If a second packet is generated in the same pass through the event loop,
the packet waiting to be sent by process_io just gets stomped
on/overwritten silently.
I fully believe that this stomping has the potential to occur during
other regular activity as well, but it may just be that it is
ordered/timed in a way that it doesn't usually cause any issue. For
example, if an OCC reply was sent in the same interval as a ping, the
ping is always going to be overwritten, but in that case w/ default
code, the ping isn't important since sending the OCC packet will have
the same effect.
It seems like some sort of combination of:
* short circuit the event loop as soon as a single packet is queued
* reduce minimum (while no other I/O) event_wait time
or - much more invasively, implement ability to queue multiple packets
to be sent.
Any thoughts on this issue?
-- Nathan
------------------------------------------------------------
Nathan Neulinger nn...@mst.edu
Missouri S&T Information Technology (573) 612-1412
System Administrator - Principal KD0DMH
--- Begin Message ---
I've got a multi-gigabit openvpn deployment, using UDP based openvpn,
set up as a bridge to provide layer 2 connectivity between two sites
over a 10 gig routed internet connection.
Everything is working great, with one problem. We've had an issue with
our intermediate network connection where our provider is randomly
filtering/blocking certain UDP flows, sometimes in only one direction,
due to an IPS they have installed between our two sites. The problem is
that openvpn - when run in UDP mode - effectively has no existing way to
detect a unidirectional link. (The underlying problem is being worked
on, but the inability to detect it automatically is my current focus.)
A ------> B
A: sends pings, never gets any traffic or ping packets, constantly
restarts/exits
B: sends pings (they never actually make it to A), but sees pings
from A, thinks everything is fine.
What I propose implementing is a small optional extension to the current
ping handling code that would request "ping confirmation". The actual
implementation of this could be relatively simple - it is after all just
an enhanced keepalive.
Upon configuration of this mode, openvpn would have the following
behavior:
1. Ping send interval and timeout would be changed to be based on
ping packets only - not 'any packet'
2. Ping packet itself would be extended to indicate a REQUEST or
REPLY.
3. On every ping interval, a ping REQUEST packet would be sent.
4. Upon receipt of any ping REPLY, timer would be reset and packet
would be dropped
5. Upon receipt of any ping REQUEST, a ping REPLY will be sent.
Obviously, this option would only be usable if both sides enabled it, so
a flag for it would be added to the options string consistency check.
This could also be implemented as a completely separate option, but I
figured it would be most useful to leverage the existing
ping/ping-restart/keepalive/etc. option syntax and simply be a flag to
request the extra behavior.
Is this something you would be interested in including in the code if I
send you a patch? I know that in our environment, it will resolve the
problem we are seeing with openvpn not being able to detect a
unidirectional UDP link.
-- Nathan
BTW, if you're interested in more info about our deployment,
performance, implementation, etc. I'll be happy to get that to you.
------------------------------------------------------------
Nathan Neulinger nn...@mst.edu
Missouri S&T Information Technology (573) 612-1412
System Administrator - Principal KD0DMH
--- End Message ---
