how to setup ssh tunnel to named virtual host running Jenkins

Question

I'm currently setting up server inside our lab at Uni that will be used for multiple purposes including a bibliography database and a CI Server (Jenkins). In order to maintain clean separation of concerns, I have a jailed Virtual Host (VH) for each function along with an assigned internal domain name. Inside the lab, the arrangement works fine. I've installed BIND9 on the server, so it is able to resolve domain names.

However, in order to connect to our lab from home, we need to first VPN into the Uni and then SSH into our lab's gateway machine. From the gateway we can access any internal machines we need to reach. Once logged into the gateway, we use SSH Tunnels as needed. Machines inside our lab cannot be directly accessed from the VPN without logging into the gateway as per the University's policy.

I'm wondering if it is possible to access virtual hosts through a single SSH tunnel? Like Server Name Indication (SNI)? Or would I need to setup a proxy server like Squid? I gather that both DNS as well as HTTP traffic would need to be routed correctly. Can this be done using just hosts file settings?

Any advice would be much appreciated. Thanks!

Update
I have continued working on the problem and have a solution that seems to work, but still has one remaining flaw; Jenkins, on the Manage page when using VPN/SSH, is complaining It appears that your reverse proxy set up is broken. Thus, whilst my requests are correct, some of my responses are not, and I would like to fix this.

The short answer is to use a reverse proxy server located on the remote machine that forwards requests to the localhost ports that are being tunnelled. The solution involved the following:
1) Since SNI is not available, it is possible in this case to assign an additional unique port to be listened to for each Virtual Host. I've chosen to use the 808x upwards range.
2) I updated the stanza in the SSH config file on my local machine which I use to connect to the gateway machine to include forwarding of all these ports.
3) I have configured a local reverse proxy on my local machine (using Apache2 in my case) to allow me to refer to each port using a domain name, thus forwarding the requests to http://localhost:808x. For the local VH's, I chosen to use the .vpn TLD to mark these as domain names for use when using VPN to connect to the lab. Thus I can use the normal .int domain name when I'm in the lab without any conflicts.

Overall, this solution seems to work well. Whilst there is an option to dismiss the error, I would like to fix it because, after reading through the documentation, it's unclear to me what the consequences would be of simply dismissing it.

So my question is now very Jenkins oriented, so I've included below the various configuration files I've setup. I'm wondering what I may have miss-configured in my reverse proxies, or whether I need to use mod_rewrite. Any advice would be appreciated.

SERVER SIDE
I have mod_proxy, mod_proxy_http, and mod_headers enabled. I've only shown the changes I've made to the default files.

ports.conf

Listen 80
### TOMCAT is running on 8081
Listen 8082
Listen 8083

jenkins.int.vhost

<VirtualHost *:80 *:8081 *:8083>

        ServerName        jenkins.int
        ProxyRequests     Off
        ProxyPreserveHost On
        AllowEncodedSlashes NoDecode

        <Proxy http://localhost:8081/*>
          Order deny,allow
          Allow from all
        </Proxy>

        ProxyPass         /  http://localhost:8081/ nocanon
        ProxyPassReverse  /  http://localhost:8081/
        ProxyPassReverse  /  http://jenkins.int/

#       Header edit Location ^http://jenkins.vpn http://jenkins.int
</VirtualHost>

/etc/defaults/jenkins

# port for HTTP connector (default 8080; disable with -1)
HTTP_PORT=8081
JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=$HTTP_PORT"

/var/lib/jenkins/jenkins.model.JenkinsLocationConfiguration.xml

<jenkinsUrl>http://jenkins.int/</jenkinsUrl>

/var/lib/jenkins/jenkins.CLI.xml

<jenkins.CLI>
  <enabled>true</enabled>
</jenkins.CLI>

This above is needed to enable scripts to run.

CLIENT SIDE

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>

    ServerName biblio.vpn

    ProxyPass / http://localhost:8082/

</VirtualHost>

<VirtualHost *:80>

    ServerName jenkins.vpn
    ProxyRequests Off
    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

    ProxyPass / http://localhost:8083/
    ProxyPassReverse / http://localhost:8083/
    ProxyPassReverse / http://jenkins.int/

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

SSH config file

LocalForward localhost:8080 server.local:8080
LocalForward localhost:8081 server.local:8081
LocalForward localhost:8082 server.local:8082
LocalForward localhost:8083 server.local:8083

Update 2

After speaking with some helpful Jenkins users on IRC, I came to the conclusion that the broken reverse proxy error/warning could be dismissed in our case.
One last, minor but nuisance issue was that the "New View" link pointed to the wrong address ("jenkins.int" instead of "jenkins.vpn"). Editing core/src/main/java/jenkins/model/NewViewLink.java and replacing Jenkins.getInstance().getRootUrl() with "/" in line 47, then rebuilding Jenkins and uploading the WAR file, fixed this problem.

Answer 1

Find out the organization's reasons for the policy of tunneling you through the gateway machine when you already are tunneled into a VPN.

• A test network dangerous to the production network could be a reason, but a content database and a CI/CD system is hardly dangerous.
• Proprietary information not for all users may need to be secured. But this otherwise could be done with authentication on all systems. Maybe a data loss prevention solution if the data is extremely sensitive or valuable.

If the firewall allowed it, you could set up front end load balancers or proxies outside the lab. Proxy user connections on web apps and such to backends and databases inside the network. Classic design for "external" facing applications.

If you must tunnel, route the lab subnet through the tunnel rather than forward individual ports with ssh. Also, VPN direct from the Internet to this lab network would be easier to use. Tunnel within a tunnel is possible, but writing a config a less technical user can use might get tricky, between any routing required and possibly multiple different VPN clients.