Mailing List Archive

openvpn experience, anyone?
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
Re: openvpn experience, anyone? [ In reply to ]
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
Re: openvpn experience, anyone? [ In reply to ]
On Sunday, 18 September 2022 08:52:13 BST 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

Could it also be an issue with MTU being too large? It should be easy to test
with:

ping -c 1 -v -M do -s 1464 <IP_address>

and decrease the packet size until gets through. Then configure your client
accordingly:

https://community.openvpn.net/openvpn/wiki/271-i-can-ping-through-the-tunnel-but-any-real-work-causes-it-to-lock-up-is-this-an-mtu-problem
Re: openvpn experience, anyone? [ In reply to ]
On 9/18/22 11:08, Michael wrote:
> On Sunday, 18 September 2022 08:52:13 BST 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
> Could it also be an issue with MTU being too large? It should be easy to test
> with:
>
> ping -c 1 -v -M do -s 1464 <IP_address>
>
> and decrease the packet size until gets through. Then configure your client
> accordingly:
>
> https://community.openvpn.net/openvpn/wiki/271-i-can-ping-through-the-tunnel-but-any-real-work-causes-it-to-lock-up-is-this-an-mtu-problem
>

That was a good idea!  Unfortunately, in this case it wasn't the cause:

-- ping  statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 331.754/331.754/331.754/0.000 ms
Re: openvpn experience, anyone? [ In reply to ]
On Sun, 2022-09-18 at 09:26 +0200, n952162 wrote:
>
> 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)
>

Is the machine that you're trying to SSH into also on the VPN? If so,
it may have a firewall rule like "allow SSH from the LAN" but be
missing a rule that says "allow SSH from the VPN interface."
Re: openvpn experience, anyone? [ In reply to ]
On 9/18/22 1:26 AM, n952162 wrote:
> I want to ssh over my openvpn connection, and I can't do it, the
> connection times out.

IMHO the first, second, and third thing to try when OpenSSH clients fail
for some reason is `-v`, `-v -v`, and `-v -v -v` in your ssh command(s).

That will almost always give you some sort of indication of the next
place to start looking.

That being said, -- assuming routing is good -- I would also question an
MTU issue. The symptoms of this are OpenSSH establishes the TCP
connection that carries the data and starts negotiating the SSH protocol
but fails part way through and starts timing out when big packets are
sent but never make it to the other end.

As Michael alluded to, trying to SSH from the local gateway to the
remote gateway can be a little tricky to configure as there can be a
couple of source IPs (local inside & local outside) as well as a couple
of destination IPs (remote outside & remote inside). Tunnels usually
cover local inside communicating with remote inside but fail to account
for any outside addresses. -- N.B. this can usually be addressed with
a judicious route statement that specifies which source address to use.



--
Grant. . . .
unix || die
Re: openvpn experience, anyone? [ In reply to ]
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