[Bug 278295] security/openvpn{,devel}: Add FIB support for ifconfig(8)

[email protected]
Newsgroups gmane.os.freebsd.devel.ports.bugs
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278295

Gert Doering <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|maintainer-feedback?(gert@g |maintainer-feedback-
                   |reenie.muc.de)              |

--- Comment #16 from Gert Doering <[email protected]> ---
Mmmh.  I wonder where "no real objection from Gert either" was coming from - I
think I clearly expressed that having local patches that bring behavioural
changes is not something the upstream project approves.  It makes
troubleshooting harder, as "verbatim sources built on FreeBSD" will show
different behaviour than "freebsd port built".

I also very clearly told Marek yesterday on IRC that I do not think this should
go forward.

The patch makes a very particular niche application work, namely, "socket and
ifconfig and route all in the same fib", which is typically not what people
expect to happen when calling "setfib 2 openvpn" (which would be what "man
setfib" says, namely "the socket is in fib 2").

So the right way forward here would be to define use cases "what is the
intended behaviour, where should socket and ifconfig/route be in that case, and
how to get there?", and then come up with an openvpn config setup to get there
- namely, "put ifconfig and route in fib x", which could be the same as the fib
the socket lives in, or not.  One approach could be to generalize the existing
`--route-table <id>` config option, and apply that to ifconfig as well (and
document it as such).

It's much harder to get it right, but it's the only way we (as OpenVPN
upstream) are willing to maintain this in the long run.

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.