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
