How to prevent URL being expanded by port number

ThinLinc
1

Hi team,

I set up latest version of the software (agent, server, tlwebaccess on the same server) to my satisfaction.

I need to get access to the server via the web access solution.

Unfortunately the URL’s get expanded by the port, for example

httpps://tl.myserver.com:9443/agent

I want it to be

httpps://tl.myserver.com/agent

I want to have access to the server from behind restrictive firewalls, which only allow port 443.

The port 9443 gets redirected to port 443 by the sslh port multiplexer software.

As another option I made some changes to my webaccess.conf.

This is part of my webaccess.hconf

*# The url to the login page. *
# Example: https://thinlinc.example.com:300/
#login_page=/
login_page=https://tl.myserver.com:443/

# The port on which to run the webserver
listen_port=9443

# This parameter controls the order and availability of TLS ciphers
# and handshake options for GnuTLS, also called a GnuTLS priority
# string.
gnutls_priority=NORMAL

O. K. I defined the login_page parameter to work around, but
strange thing, even though the login page defines the port “443”, instead the generated URL contains the wrong string “9443” - httpps://tl.myserver.com:9443/agent
So the wrong port is getting inserted after being logged in (…/agent).

And yes, I restarted all processes to apply all changes.

I kindly ask you to verify, and give some opinion on that.

Martin.

P. S. Don’t stumble upon “httpps” - this system does not allow for more than two URLs so I needed to do this trick…

2

Well, I went to the source code and replaced the $targetserver in main.tmpl with my URL
This solved the problem for me, maybe there is a cleaner way?

3

Hello,

I don’t think there’s an easy way around it. Browsers will always the display the port number in the address field if it is not a standard port 80 or 443.

Kind regards,
Martin

4

Thank you,

but what is the use of the " login_page" entry if it does not get respected?

5

Hello @MSK

The login_page URL, which is used to redirect back to the Web Access login page on the master server. The default value is / , which redirects to the current server. This parameter needs to be changed when ThinLinc Web Access is used in a cluster setup.

In a single server setup, redirect to / is usually fine, but as stated above (from the manual) this will redirect the user back to the current agent, and not to the master server, which is normally the desired behavior in such scenarios.

It was never meant to do port redirection as well, it will use what is defined in listen_port.

I understand that the example given in the configuration file

# Example: https://thinlinc.example.com:300/

Can sometimes be misleading that it will also do port translations, but it will not.

6

Very good to know, well, the topic can be closed now I guess.

Martin.

1 Like
7

Sorry to dig out this old topic. I’ve exactly the same problem to remove the port number. What exactly must be changed in main.tmpl concerning $targetserver?
An example would be great.

8

Hi @Ginsterkatze,

I’m a bit hesitant to recommend modifying ThinLinc files, since this will mean we are unable to provide you with support. There is also the risk of any changes being overwritten during an upgrade.

However, if you’re happy to take responsibility, the file being discussed above is located at /opt/thinlinc/share/tlwebaccess/main.tmpl. In there you will find the $targetserver variable which can be substituted with the desired URL.

I have added a bug in our tracker for this, feel free to subscribe to it if you wish:

https://bugzilla.cendio.com/show_bug.cgi?id=8388

9

Hi Aaron, thank you very much!

I understand your point about not recommending changes that affect support. It would be nice if the bug tracker allows there to be a port option in one of the next versions.
My knowledge of scripting is limited to say the least. Do you perhaps have an example of what line of source code I need to add to change the value of $targetsever in main.tmpl. I of course take full responsibility for any unwanted side effects.

10

There are two instances of the string $qh($targetserver) in that file, both relating to the form element. I don’t have a server to test this on at the moment, but replacing those strings with the URL (and port number) of your server should do the trick.

11

Great, now it works exactly as I wanted it to.
Your tip to set the port number was the breakthrough.
I hadn’t specified it and that was exactly the mistake.

12

Great to hear. I hope this temporary fix will enable you to continue with your testing and evaluation until such time as an approved solution is available :wink: