Re: [gentoo-user] openvpn experience, anyone?

[n952162]

On 9/18/22 14:23, William Kenworthy wrote:
>
> On 18/9/22 16:26, n952162 wrote:
>>
>> On 9/18/22 09:52, William Kenworthy wrote:
>>>
>>> On 18/9/22 15:26, n952162 wrote:
>>>> Hello all,
>>>>
>>>> I want to ssh over my openvpn connection, and I can't do it, the
>>>> connection times out.
>>>>
>>>> I saw a reference to gentoo in the openvpn scripts in /etc/openvpn and
>>>> thought maybe somebody here  knows something about this.
>>>>
>>>> Earlier my institution recommended openconnect, and I was able to use
>>>> ssh to login in to a host with no problem.
>>>>
>>>> Then, for some reason (licensing?), we were switched to openvpn, which
>>>> works for xfreerdp but not for ssh.
>>>>
>>>> I don't have control over the institution's firewall (but I do have
>>>> for
>>>> the host itself)
>>>>
>>>> Perhaps when installing the new service, they tightened up the
>>>> firewall
>>>> rules.  But maybe there's a configuration screw I can turn, or ...
>>>> maybe
>>>> a USE flag?
>>>>
>>>> - - down-root : Enable the down-root plugin
>>>>  - - examples  : Install examples, usually source code
>>>>  - - inotify   : Enable inotify filesystem monitoring support
>>>>  - - iproute2  : Enabled iproute2 support instead of net-tools
>>>>  + + lz4       : Enable support for lz4 compression (as implemented in
>>>> app-arch/lz4)
>>>>  + + lzo       : Enable support for lzo compression
>>>>  - - mbedtls   : Use mbed TLS as the backend crypto library
>>>>  + + openssl   : Use OpenSSL as the backend crypto library
>>>>  + + pam       : Add support for PAM (Pluggable Authentication
>>>> Modules)
>>>> - DANGEROUS to
>>>>                  arbitrarily flip
>>>>  - - pkcs11    : Enable PKCS#11 smartcard support
>>>>  + + plugins   : Enable the OpenVPN plugin system
>>>>  - - systemd   : Enable use of systemd-specific libraries and features
>>>> like socket
>>>>                  activation or session tracking
>>>>  - - test      : Enable dependencies and/or preparations necessary to
>>>> run tests
>>>>                  (usually controlled by FEATURES=test but can be
>>>> toggled independently)
>>>>
>>>> TIA
>>>>
>>>>
>>> ssh and openvpn work well together.  However I am doing most of the
>>> work using my own configs - gentoo tries to be too clever with its vpn
>>> networking and Ive never been able to get it to work
>>> reliably/acceptably.  On some sites I have to use port 443 (https) to
>>> get through, and in extreme cases double wrap in ssl (using a mix of
>>> proxytunnel (windows host), stunnel and sslh) to disguise its a vpn
>>> but still separate it from regular https traffic on my firewall.  You
>>> will need to figure out where the ssh is getting blocked/stripped out
>>> - is openvpn your endpoint or theirs?
>>>
>>> BillK
>>>
>>>
>>>
>>
>> I don't understand that question: "is openvpn your endpoint or theirs" -
>> don't both sides have an endpoint on the tunnel?
>>
>> That would have been a class idea, using the https port ...
>> unfortunately, there's a web server running on that machine... it's not
>> being used, however ... hmmm.
>>
>> Wow: "in extreme cases double wrap in ssl (using a mix of proxytunnel
>> (windows host), stunnel and sslh) to disguise its a vpn but still
>> separate it from regular https traffic on my firewall." - sounds totally
>> cool, except I have no idea what it means... which concept should I
>> start with?
>>
>> - proxytunnel
>>
>> - sslh
>>
>> - double wrapping in ssl
>>
> 1. Do you have control over both openvpn endpoints?  Typically in a
> roadwarrior setup the company IT dept owns one and you don't get
> access to it which can make it very difficult to see whats going on -
> if you can access the configs of both ends its much easier. The
> firewall you mention might be dropping ssh packets exiting the tunnel
> if its hosting an endpoint that is subject to the firewall?  Routing
> multiple hops past the vpn endpoint can be another issue with openvpn.
>

Ah, now I have a  better understanding of the question - yes,
unfortunately, the vpn goes to the institution's intranet.  I control
the client and the host, and the link to the institution, but the remote
endpoint of the tunnel is not in my control.



> 2. SSL packets have identifiers in the headers that indicate the type
> of traffic within - sslh is a multiplexor that detects openvpn,
> openssl, openssh etc. via the ssl packet headers (does not need to see
> into the encryption to do this) and redirects the packets to different
> hosts/ports as applicable - e.g, ssl web traffic to your web server
> and openvpn ssl to to the vpn concentrator even though it all comes in
> as ssl on port 443.


Okay, that gets me a lot closer.   Thank you.

>
> 3a. Before retiring I was working within various seriously locked down
> networks and needed to reach my own home server - some of the
> commercial firewalls are able to break and examine ssl streams, or
> identify it was openvpn on port 443 and block it.  If you are using a
> commercial certificate with openvpn this may be happening.
>
> 3b. If you own/host both ends of the vpn tunnel on your own machines,
> use the end-to-end encryption options, and a private certificate. By
> feeding the openvpn ssl stream through something like proxytunnel you
> are encrypting the stream a second time with https characteristics
> which gets around this to some degree (if they do bother break out the
> ssl, they are presented with the original encrypted data stream and
> assume its just random data - so far!).  To extract the data from the
> original two times encrypted stream I use an sslh multiplexor instance
> to split https from openvpn traffic coming in on port 443.  The
> openvpn goes to the vpn concentrator while the ssl goes to a stunnel
> instance to strip that ssl layer after which its sent to a second sslh
> instance to separate the now non-ssl http traffic to send to the
> webserver, and the recovered original openvpn stream to the
> concentrator.  Ive had this working for years and performance is
> actually quite good despite its convoluted configuration!


Yeah, some heavy-duty lifting, I'll work on that incrementally ;-)


>
> It gets a lot more complex if firewall pin-holing and other techniques
> are needed :) - firewalls are not all that secure these days!  Hope I
> have not totally lost you!
>
> BillK
>
>

Thanks alot!  Very concise and at the same time educational

cts