Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-30 Thread Joe Patterson
My previous attempt was a client-connect script that directly added
static routes to quagga via vtysh commands. It worked... usually.
Sometimes.

I see what you're saying about adding iroutes dynamically
post-connect.  I skirt this issue by using OSPF on p2p links between
my openvpn servers, then using my client-connect script or my
management daemon to add ifconfig-push'd static IP addresses or
iroutes from CCD files to the routing table when p2mp clients connect.
So I have no facility for adding a new iroute to a particular client
beyond restarting the connection.  I can definitely understand how
that could be challenging.

On Thu, Apr 30, 2020 at 2:14 PM Gert Doering  wrote:
>
> Hi,
>
> On Thu, Apr 30, 2020 at 01:53:29PM -0400, Joe Patterson wrote:
> > So, I've got a back-burner project that does parts of this.  It's a
> > daemon that connects to the management console and handles things like
> > client auth and such.  The way I did it was that the daemon keeps an
> > internal copy of basically the iroute table, and then advertises it
> > via RIPv2 on localhost.  I can then set up quagga to listen for RIP on
> > localhost and redistribute RIP-learned routes via OSPF.  At some point
> > I will probably share it to the world, as it does some other handy
> > things as well, and also because I am not a master coder, so I'm sure
> > it could be improved upon by smarter folks than me.
>
> Nice.
>
> It's the easier part of the whole thing, though... (You can do the
> "learn about iroute and put into kernel routing" part in client-connect
> scripts as well, and radiusplugin is also doing something along those
> lines to get radius-provided routes installed).
>
> The part that is - as far as I am aware - totally impossible today is
> "while a client is connected, tell OpenVPN that a new iroute is needed
> for this client" (which would be needed if OSPF decides "hey, I want
> to route  to ").
>
> We have a trac ticket for this, somewhere, and all progress we've
> made so far was "uh, this is hard, and there be dragons" :-)
>
> gert
>
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never doubted
>  it myself till I met a computer with a sense of humor."
>  Robert A. Heinlein, The Moon is a Harsh Mistress
>
> Gert Doering - Munich, Germany g...@greenie.muc.de


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-30 Thread Gert Doering
Hi,

On Thu, Apr 30, 2020 at 01:53:29PM -0400, Joe Patterson wrote:
> So, I've got a back-burner project that does parts of this.  It's a
> daemon that connects to the management console and handles things like
> client auth and such.  The way I did it was that the daemon keeps an
> internal copy of basically the iroute table, and then advertises it
> via RIPv2 on localhost.  I can then set up quagga to listen for RIP on
> localhost and redistribute RIP-learned routes via OSPF.  At some point
> I will probably share it to the world, as it does some other handy
> things as well, and also because I am not a master coder, so I'm sure
> it could be improved upon by smarter folks than me.

Nice.

It's the easier part of the whole thing, though... (You can do the 
"learn about iroute and put into kernel routing" part in client-connect 
scripts as well, and radiusplugin is also doing something along those
lines to get radius-provided routes installed).

The part that is - as far as I am aware - totally impossible today is
"while a client is connected, tell OpenVPN that a new iroute is needed
for this client" (which would be needed if OSPF decides "hey, I want 
to route  to ").

We have a trac ticket for this, somewhere, and all progress we've
made so far was "uh, this is hard, and there be dragons" :-)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-30 Thread Joe Patterson
So, I've got a back-burner project that does parts of this.  It's a
daemon that connects to the management console and handles things like
client auth and such.  The way I did it was that the daemon keeps an
internal copy of basically the iroute table, and then advertises it
via RIPv2 on localhost.  I can then set up quagga to listen for RIP on
localhost and redistribute RIP-learned routes via OSPF.  At some point
I will probably share it to the world, as it does some other handy
things as well, and also because I am not a master coder, so I'm sure
it could be improved upon by smarter folks than me.

-Joe

On Thu, Apr 30, 2020 at 1:25 PM Gert Doering  wrote:
>
> Hi,
>
> On Thu, Apr 30, 2020 at 02:51:25PM +0200, free...@tango.lu wrote:
> > I guess in 2020 we should be done with that type of crap quality. Just
> > write a proper step by step howto please on OSPF+OpenVPN
>
> Please do so!  You are the one who wants to do this, so please share
> your experience when you have it working.
>
> > but what would
> > be even better to have an "ospf" one liner option and when you put that
> > into the OpenVPN config it will just do the magic trick.
>
> Someone will need to implement this in OSPF.  I explained what is needed
> to do it, now it "just needs to be done".
>
> It requires a fairly deep understanding about routing, OpenVPN iroute
> vs. Linux kernel routing, netlink, and C code...  so maybe there's only
> Antonio (and maybe I) today who can do it, but the craft can be learned :-)
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never doubted
>  it myself till I met a computer with a sense of humor."
>  Robert A. Heinlein, The Moon is a Harsh Mistress
>
> Gert Doering - Munich, Germany g...@greenie.muc.de
> ___
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-30 Thread Gert Doering
Hi,

On Thu, Apr 30, 2020 at 02:51:25PM +0200, free...@tango.lu wrote:
> I guess in 2020 we should be done with that type of crap quality. Just 
> write a proper step by step howto please on OSPF+OpenVPN 

Please do so!  You are the one who wants to do this, so please share
your experience when you have it working.

> but what would 
> be even better to have an "ospf" one liner option and when you put that 
> into the OpenVPN config it will just do the magic trick.

Someone will need to implement this in OSPF.  I explained what is needed
to do it, now it "just needs to be done".

It requires a fairly deep understanding about routing, OpenVPN iroute
vs. Linux kernel routing, netlink, and C code...  so maybe there's only
Antonio (and maybe I) today who can do it, but the craft can be learned :-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-30 Thread Don
Hello,
I stumbled upon a youtube video mentioning OSPF routing search for:
OpenVPN site-to-site on Edgerouter (OSPF Routing)
https://www.youtube.com/watch?v=ee_OwM_MDfk
Don

On 4/30/20 8:51 AM, free...@tango.lu wrote:
> On 2020-04-29 22:19, Nathan Stratton Treadway wrote:
>> On Wed, Apr 29, 2020 at 05:34:14 -0400, Jonathan K. Bullard wrote:
>>> Hi,
>>>
>>> On Wed, Apr 29, 2020 at 3:43 AM Gert Doering 
>>> wrote:
>>> > On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote:
>>> > > Which makes me think OSPF is only possible with the old tap
>>> interfaces,
>>> > > what the OpenVPN dev team even want to remove in the future, why is
>>> > > there no proper support of OSPF in routed tun tunnels?
>>> >
>>> > Not sure where that rumor is coming from.  No removal of TAP device
>>> > support is planned.
>>>
>>> I don't know where the rumor started, but I can understand why it is
>>> plausible:
>>>
>>> (A) The OpenVPN developers discourage the use of TAP connections,
>>> saying, for example "Layer 3 is for a number of reasons the better
>>> choice anyways" [1];
>>> (B) The "OpenVPN Connect" Android and iOS apps do not support TAP
>>> connections [1][2]; and
>>> (C) Apple has deprecated loading the system extension that Tunnelblick
>>> uses to create a TAP device and, on the latest version of macOS, pops
>>> up a warning saying the extension "will be incompatible with future
>>> versions of macOS" [3].
>>
>> Expanding further on those points, there was a discussion of this topic
>> here on this list back in March 2019, under the Subject "Removal of the
>> TAP Bridge, Strange ARP issue and looking for solutions for an
>> alternative Layer2 VPN", e.g.
>>   https://sourceforge.net/p/openvpn/mailman/message/36606924/
>> or
>>  
>> https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04759.html
>> .
>>
>> That disussion makes clear that in fact OpenVPN _3_ specifically does
>> *not* include support for TAP (at least as currently implemented).
>>
>> The discussion does go on to explain that that all releases of OpenVPN
>> _2.x_ will continue include TAP support and that v2 "will live for a
>> long time to come"... but I can certainly understand "casual" users
>> being confused by this distinction.
>>
>> The OP in that thread did not give an explicit reference to the origin
>> of his/her information regarding TAP support/"bridged networking",
>> so I'm not sure what would have helped avoid the confusion there...
>>
>> ... but I searched around a bit in the Community Wiki and though there
>> are a number of pages that mention specific OpenVPN 3 software packages,
>> I didn't find any general page explaining the differences-between and
>> future-plans-for the v2 and v3 (and "Connect") product lines, etc.  --
>> something like that might help clear up (a little of) this sort of
>> confusion.
>>
>>
>>     Nathan
>>
>> 
>>
>> Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
>> Ray Ontko & Co.  -  Software consulting services  -  
>> http://www.ontko.com/
>>  GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID:
>> 1023D/ECFB6239
>>  Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239
>>
>>
>> ___
>> Openvpn-users mailing list
>> Openvpn-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> I'm sorry I didn't recall what I wrote couple of months ago but it's
> amusing that some people even takes the time to read up on old dirt
> and if we talk about dirt this NetGate article is the shining example
> what would qualify for some bath room writing hodge-podge where the
> author didn't give half a shit even to use a  [code] statement
> (most likely even that config he posted is broken).
>
> That kind of shitty forum posts described the linux community well for
> the last 20 years. Someone might knows the right answer or might find
> it later so he leaves a half finished rant which does not work and
> most of the readers don't even understand and let them find it out on
> their own and when they do they will of course NOT share the right
> answer with anyone LOL.
>
> I guess in 2020 we should be done with that type of crap quality. Just
> write a proper step by step howto please on OSPF+OpenVPN but what
> would be even better to have an "ospf" one liner option and when you
> put that into the OpenVPN config it will just do the magic trick.
>
> Thank you :)
>
>
> ___
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-30 Thread freebsd

On 2020-04-29 22:19, Nathan Stratton Treadway wrote:

On Wed, Apr 29, 2020 at 05:34:14 -0400, Jonathan K. Bullard wrote:

Hi,

On Wed, Apr 29, 2020 at 3:43 AM Gert Doering  
wrote:

> On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote:
> > Which makes me think OSPF is only possible with the old tap interfaces,
> > what the OpenVPN dev team even want to remove in the future, why is
> > there no proper support of OSPF in routed tun tunnels?
>
> Not sure where that rumor is coming from.  No removal of TAP device
> support is planned.

I don't know where the rumor started, but I can understand why it is 
plausible:


(A) The OpenVPN developers discourage the use of TAP connections,
saying, for example "Layer 3 is for a number of reasons the better
choice anyways" [1];
(B) The "OpenVPN Connect" Android and iOS apps do not support TAP
connections [1][2]; and
(C) Apple has deprecated loading the system extension that Tunnelblick
uses to create a TAP device and, on the latest version of macOS, pops
up a warning saying the extension "will be incompatible with future
versions of macOS" [3].


Expanding further on those points, there was a discussion of this topic
here on this list back in March 2019, under the Subject "Removal of the
TAP Bridge, Strange ARP issue and looking for solutions for an
alternative Layer2 VPN", e.g.
  https://sourceforge.net/p/openvpn/mailman/message/36606924/
or
  
https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04759.html

.

That disussion makes clear that in fact OpenVPN _3_ specifically does
*not* include support for TAP (at least as currently implemented).

The discussion does go on to explain that that all releases of OpenVPN
_2.x_ will continue include TAP support and that v2 "will live for a
long time to come"... but I can certainly understand "casual" users
being confused by this distinction.

The OP in that thread did not give an explicit reference to the origin
of his/her information regarding TAP support/"bridged networking",
so I'm not sure what would have helped avoid the confusion there...

... but I searched around a bit in the Community Wiki and though there
are a number of pages that mention specific OpenVPN 3 software 
packages,

I didn't find any general page explaining the differences-between and
future-plans-for the v2 and v3 (and "Connect") product lines, etc.  --
something like that might help clear up (a little of) this sort of
confusion.


Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   
http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 
1023D/ECFB6239

 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
I'm sorry I didn't recall what I wrote couple of months ago but it's 
amusing that some people even takes the time to read up on old dirt and 
if we talk about dirt this NetGate article is the shining example what 
would qualify for some bath room writing hodge-podge where the author 
didn't give half a shit even to use a  [code] statement (most 
likely even that config he posted is broken).


That kind of shitty forum posts described the linux community well for 
the last 20 years. Someone might knows the right answer or might find it 
later so he leaves a half finished rant which does not work and most of 
the readers don't even understand and let them find it out on their own 
and when they do they will of course NOT share the right answer with 
anyone LOL.


I guess in 2020 we should be done with that type of crap quality. Just 
write a proper step by step howto please on OSPF+OpenVPN but what would 
be even better to have an "ospf" one liner option and when you put that 
into the OpenVPN config it will just do the magic trick.


Thank you :)


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support --"TAP support removal" rumor

2020-04-29 Thread Nathan Stratton Treadway
On Wed, Apr 29, 2020 at 05:34:14 -0400, Jonathan K. Bullard wrote:
> Hi,
> 
> On Wed, Apr 29, 2020 at 3:43 AM Gert Doering  wrote:
> > On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote:
> > > Which makes me think OSPF is only possible with the old tap interfaces,
> > > what the OpenVPN dev team even want to remove in the future, why is
> > > there no proper support of OSPF in routed tun tunnels?
> >
> > Not sure where that rumor is coming from.  No removal of TAP device
> > support is planned.
> 
> I don't know where the rumor started, but I can understand why it is 
> plausible:
> 
> (A) The OpenVPN developers discourage the use of TAP connections,
> saying, for example "Layer 3 is for a number of reasons the better
> choice anyways" [1];
> (B) The "OpenVPN Connect" Android and iOS apps do not support TAP
> connections [1][2]; and
> (C) Apple has deprecated loading the system extension that Tunnelblick
> uses to create a TAP device and, on the latest version of macOS, pops
> up a warning saying the extension "will be incompatible with future
> versions of macOS" [3].

Expanding further on those points, there was a discussion of this topic
here on this list back in March 2019, under the Subject "Removal of the
TAP Bridge, Strange ARP issue and looking for solutions for an
alternative Layer2 VPN", e.g.
  https://sourceforge.net/p/openvpn/mailman/message/36606924/
or
  https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04759.html
.

That disussion makes clear that in fact OpenVPN _3_ specifically does
*not* include support for TAP (at least as currently implemented).

The discussion does go on to explain that that all releases of OpenVPN
_2.x_ will continue include TAP support and that v2 "will live for a
long time to come"... but I can certainly understand "casual" users
being confused by this distinction.

The OP in that thread did not give an explicit reference to the origin
of his/her information regarding TAP support/"bridged networking",
so I'm not sure what would have helped avoid the confusion there...

... but I searched around a bit in the Community Wiki and though there 
are a number of pages that mention specific OpenVPN 3 software packages,
I didn't find any general page explaining the differences-between and
future-plans-for the v2 and v3 (and "Connect") product lines, etc.  --
something like that might help clear up (a little of) this sort of
confusion.


Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Gert Doering
Hi,

On Wed, Apr 29, 2020 at 04:45:14PM +0200, Jan Just Keijser wrote:
> it does make me wonder what the posts were about of people using 
> openvpn+tun+pfsense/quagga - some even more than 10 yrs ago!

p2p mode, mayhaps?

(IPv6 worked in p2p mode also much much earlier than in p2mp mode - 
mostly a question of prodding the kernel driver for "yes, multiprotocol!",
but then just forwarding packets back and forth.  IPv6 in p2mp mode
required teaching iroute about IPv6...)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Jan Just Keijser

Hi Gert,

On 29/04/20 13:11, Gert Doering wrote:

Hi,

On Wed, Apr 29, 2020 at 12:45:26PM +0200, Gert Doering wrote:

On Wed, Apr 29, 2020 at 12:25:02PM +0200, Jan Just Keijser wrote:

in other words, OSPF is not UDP or TCP based and hence will not easily
work over routed tunnels - which makes sense, as OSPF is a rout*ING
*protocol, not a rout*ED* protocol.

Naaah.

To word this a bit more explitly :-)

OpenVPN in p2p mode will transport everything that is running on top
of IPv4 or IPv6.  So, no "UDP or TCP based" (otherwise "ping" wouldn't
work).  It will transport OSPF / OSPFv3 packets just fine.

It might or might not transport non-IP stuff, like IPX or ISO (which
would be needed for IS-IS routing).  Theoretically it should, but I
would assume some checks for v4/v6 and subsequent packet explosion.


Now, p2mp mode.  In p2mp mode, the server needs to understand what to
do with the packet (server-internal routing table, "iroute" stuff).

OSPF does multicast, which is somewhat half-implemented into OpenVPN -
namely, multicast packets get treated as broadcasted.  Which is what
is needed here: make sure OSPF packets get to all tun clients
(drawback: also to those that are not running OSPF, so don't mix).

This should also work "just fine", because the server's routing is
also not based on "UDP or TCP based", just on IPv4/IPv6 target address
inside the tunnel.

Next, OSPF exchanges IPv4/IPv6 routing info, and this is programmed into
the kernel routing table left and right.  *This* is where OSPF breaks
in p2mp mode, because this kernel routing info is not propagating into
the OpenVPN server iroute table.





thanks for correcting me, as always ;)
it does make me wonder what the posts were about of people using 
openvpn+tun+pfsense/quagga - some even more than 10 yrs ago!


cheers,

JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Gert Doering
Hi,

On Wed, Apr 29, 2020 at 12:45:26PM +0200, Gert Doering wrote:
> On Wed, Apr 29, 2020 at 12:25:02PM +0200, Jan Just Keijser wrote:
> > in other words, OSPF is not UDP or TCP based and hence will not easily 
> > work over routed tunnels - which makes sense, as OSPF is a rout*ING 
> > *protocol, not a rout*ED* protocol.
> 
> Naaah.

To word this a bit more explitly :-)

OpenVPN in p2p mode will transport everything that is running on top
of IPv4 or IPv6.  So, no "UDP or TCP based" (otherwise "ping" wouldn't
work).  It will transport OSPF / OSPFv3 packets just fine.

It might or might not transport non-IP stuff, like IPX or ISO (which
would be needed for IS-IS routing).  Theoretically it should, but I
would assume some checks for v4/v6 and subsequent packet explosion.


Now, p2mp mode.  In p2mp mode, the server needs to understand what to
do with the packet (server-internal routing table, "iroute" stuff).

OSPF does multicast, which is somewhat half-implemented into OpenVPN - 
namely, multicast packets get treated as broadcasted.  Which is what
is needed here: make sure OSPF packets get to all tun clients
(drawback: also to those that are not running OSPF, so don't mix).

This should also work "just fine", because the server's routing is
also not based on "UDP or TCP based", just on IPv4/IPv6 target address
inside the tunnel.

Next, OSPF exchanges IPv4/IPv6 routing info, and this is programmed into
the kernel routing table left and right.  *This* is where OSPF breaks
in p2mp mode, because this kernel routing info is not propagating into
the OpenVPN server iroute table.



In *TAP* mode, just for completeness, OpenVPN does not care at all
for protocol numbers or IPv4/IPv6 routing.  All it does is "I am an
ethernet switch, and I will send out packets based on MAC address",
so routing (which will install a next-hop to something identifiable
by ARP and then given to OpenVPN with a known destination MAC address)
will work nicely.  IS-IS, IPX, ISO networking might also "just work",
because it's "just ethernet frames".

The reason why (Jonathan pointed this out) the OpenVPN devs usually
recommend away from TAP mode is that TAP brings more overhead (extra
ethernet header inside each VPN packet, extra ARP packets, ...) and
has no benefits for a "normal" L3 routed setup.  Worded differently, if
what you want can be done inside OpenVPN routing, tun mode is what
you want, because it is more efficient.

If you need stuff like "bridge together two networks so that Netbios
broadcasting works", TAP mode is it for you, or use a WINS or AD server 
instead :-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Gert Doering
Hi,

On Wed, Apr 29, 2020 at 12:25:02PM +0200, Jan Just Keijser wrote:
> in other words, OSPF is not UDP or TCP based and hence will not easily 
> work over routed tunnels - which makes sense, as OSPF is a rout*ING 
> *protocol, not a rout*ED* protocol.

Naaah.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Jan Just Keijser



On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote:

Ok so after a bit of research and finding half baked articles such as:
https://superuser.com/questions/1283125/proper-configuration-for-quagga-ospf-on-an-openvpn-network

Which makes me think OSPF is only possible with the old tap interfaces,
what the OpenVPN dev team even want to remove in the future, why is
there no proper support of OSPF in routed tun tunnels?



from
 https://en.wikipedia.org/wiki/Open_Shortest_Path_First

"https://en.wikipedia.org/wiki/Open_Shortest_Path_First*";
*
"Unlike other routing protocols, OSPF does not carry data via a 
transport protocol, such as the User Datagram Protocol (UDP) or the 
Transmission Control Protocol (TCP). Instead, OSPF forms IP datagrams 
directly, packaging them using protocol number 89 for the IP Protocol 
field."


in other words, OSPF is not UDP or TCP based and hence will not easily 
work over routed tunnels - which makes sense, as OSPF is a rout*ING 
*protocol, not a rout*ED* protocol.
Having said that, lots of people have posted info on how to set up OSPF 
over a tun-based openvpn setup. e.g

 https://forum.netgate.com/topic/117806/solved-running-ospf-on-tun-openvpn


HTH,

JJK

**
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Jonathan K. Bullard
Hi,

On Wed, Apr 29, 2020 at 3:43 AM Gert Doering  wrote:
>
> Hi,
>
> On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote:
> > Ok so after a bit of research and finding half baked articles such as:
> > https://superuser.com/questions/1283125/proper-configuration-for-quagga-ospf-on-an-openvpn-network
> >
> > Which makes me think OSPF is only possible with the old tap interfaces,
> > what the OpenVPN dev team even want to remove in the future, why is
> > there no proper support of OSPF in routed tun tunnels?
>
> Not sure where that rumor is coming from.  No removal of TAP device
> support is planned.

I don't know where the rumor started, but I can understand why it is plausible:

(A) The OpenVPN developers discourage the use of TAP connections,
saying, for example "Layer 3 is for a number of reasons the better
choice anyways" [1];
(B) The "OpenVPN Connect" Android and iOS apps do not support TAP
connections [1][2]; and
(C) Apple has deprecated loading the system extension that Tunnelblick
uses to create a TAP device and, on the latest version of macOS, pops
up a warning saying the extension "will be incompatible with future
versions of macOS" [3].

Best regards,

Jon Bullard

[1] 
https://openvpn.net/vpn-server-resources/faq-regarding-openvpn-connect-android/#Why_does_the_app_not_support_TAP-style_tunnels
[2] 
https://openvpn.net/vpn-server-resources/faq-regarding-openvpn-connect-ios/#Why_doesnt_the_app_support_tap-style_tunnels
[3] https://tunnelblick.net/cTunTapConnections.html


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Antonio Quartulli
Hi,

On 29/04/2020 09:03, free...@tango.lu wrote:
> Ok so after a bit of research and finding half baked articles such as:
> https://superuser.com/questions/1283125/proper-configuration-for-quagga-ospf-on-an-openvpn-network
> 
> 
> Which makes me think OSPF is only possible with the old tap interfaces,
> what the OpenVPN dev team even want to remove in the future, why is
> there no proper support of OSPF in routed tun tunnels?

What makes you think that OSPF (or BGP) can't just work over tun interfaces?

It should just work as it does over any other IP tunnel.

Did you hit any problem while running it?

> 
> Is there no demand of using routing protocols inside VPN tunnels? Any
> plans for the future to have something like quagga built into OpenVPN to
> take care of this?

No - I don't think there is a real reason to have it built-in.

Cheers,

-- 
Antonio Quartulli


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread Gert Doering
Hi,

On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote:
> Ok so after a bit of research and finding half baked articles such as:
> https://superuser.com/questions/1283125/proper-configuration-for-quagga-ospf-on-an-openvpn-network
> 
> Which makes me think OSPF is only possible with the old tap interfaces, 
> what the OpenVPN dev team even want to remove in the future, why is 
> there no proper support of OSPF in routed tun tunnels?

Not sure where that rumor is coming from.  No removal of TAP device
support is planned.

OSPF over tun works fine *if* you do p2p tun.

It does not work if you have a point-to-multipoint server involved
("--server") because that one has an internal routing table which is
not synchronized to the kernel side.  So OSPF might speak through
the tunnel, but the routes exchanged are not learned by OpenVPN,
and so packets can not flow.

> Is there no demand of using routing protocols inside VPN tunnels? Any 
> plans for the future to have something like quagga built into OpenVPN to 
> take care of this?

Antonio has recently started a discussion about "can we not synchronize
the OpenVPN iroute table with the kernel routing table".  This would
enable BGP/OSPF/... on top of openvpn tunnels, but it is not trivially
done.  Like, quite *very* difficult to get right.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


[Openvpn-users] OpenVPN with OSPF there is no proper guide or support

2020-04-29 Thread freebsd

Ok so after a bit of research and finding half baked articles such as:
https://superuser.com/questions/1283125/proper-configuration-for-quagga-ospf-on-an-openvpn-network

Which makes me think OSPF is only possible with the old tap interfaces, 
what the OpenVPN dev team even want to remove in the future, why is 
there no proper support of OSPF in routed tun tunnels?


Is there no demand of using routing protocols inside VPN tunnels? Any 
plans for the future to have something like quagga built into OpenVPN to 
take care of this?



My setup would be something common:

3 locations

A 10.0.1.0/24
B 10.0.2.0/24
C 10.0.3.0/24

With point to point tunnels between all 3 locations with OpenVPN in 
routed mode.

The tunnels use different p2p ips like:

A->B 192.168.1.1 192.168.1.2
B->C 192.168.1.3 192.168.1.4
A->C 192.168.1.5 192.168.1.6

So manually for example for hosts on A to reach computers on B you would 
add a route like:


route add -net 10.0.2.0/24 gw 192.168.1.2

However with these static routes if the connection goes down between A 
and B and both A and C and B and C is up it will not be rerouted on the 
other path. This is where OSPF would be useful.


I wonder how others deal with these kind of setups?

Thanks


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users