# Configured Thinlinc Server but new installed second network card no access

**URL:** <https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138>\
**Category:** Community Support\
**Tags:** dns, networking, dhcp, tlserver\
**Created:** [29 March 2021 21:13 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138 "2021-03-29T21:13:18Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![gwagon](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@gwagon](https://community.thinlinc.com/u/gwagon)\
**Post date:** [29 March 2021 21:13 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/1 "2021-03-29T21:13:18Z")

</div>

Dear folk,

I have a thinlinc server on a ubuntu computer which is working and reachable from network 192.168.0.1/24 with dhcp server 1 such that all clients can work with the thinlinc client software. I have installed a second network card on the server with its own dhcp server 2 on the network 192.168.1.1/24.

When a client is on the second network 192.168.1.1/24 he or she can build a ssh connection to the ubuntu server via terminal but, now the problem is, if I try to build a connection via the thinlinc client it tries to reach the thinlinc server at 192.168.0.1 but this fails and the thinlinc client doesnt change and it stays frozen.

How do I have to set the thinlinc server OR the ubuntu network configuration such that clients on the second network 192.168.2.1/24 will get through the second nic a connection to the thinlinc server which was initally configured on the 192.168.0.1/24 network???

We need this due to network balance reasons such that many users are can work on both network cards.

Please give me a help I would be very thankful.

Regards  
Juli

---

<div class="post-metadata">

**Author:** ![aaron](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/aaron/32/13_2.png) [@aaron](https://community.thinlinc.com/u/aaron)\
**Post date:** [30 March 2021 18:02 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/2 "2021-03-30T18:02:40Z")

</div>

@gwagon what is your `agent_hostname` parameter (see [here](https://www.cendio.com/resources/docs/tag/ch14s02.html#configuration_vsmagent)) set to in `vsmagent.hconf`? You can check like this:

`$ tl-config /vsmagent/agent_hostname`

The ThinLinc client makes two connections per login, one to the master and one to the agent. In your case, both master and agent are on the same machine. The agent is identified to the client using this `agent_hostname` parameter, and if this parameter is set to your `192.168.0.1` address, this is what the client will try to use for the second connection, regardless of which network it is on.

If I understand your setup correctly, you would need to use some kind of split-DNS configuration. For example, you would need to set `agent_hostname` to a resolvable hostname (e.g. `agent.example.com`), and make sure that this hostname resolves correctly for each client. That is, it would need to resolve to `192.168.0.1` for clients on the `192.168.0.0/24` network, and `192.168.1.1` for clients on the `192.168.1.0/24` network.

Another option would be to run ThinLinc in cluster mode (see [here](https://www.cendio.com/resources/docs/tag/configuration.html#configuration_cluster)). So you would have one master server and several agents, all on the same network, but each with their own network interface. ThinLinc will then load-balance sessions across each agent in the cluster.

HTH

---

<div class="post-metadata">

**Author:** ![gwagon](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@gwagon](https://community.thinlinc.com/u/gwagon)\
**Post date:** [31 March 2021 16:34 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/3 "2021-03-31T16:34:28Z")

</div>

Dear Aaron,

thank you very much for your reply and friendly statement.

I looked up and tl-config /vsmagent/agent\_hostname gives me empty message and after I looked up in /opt/thinlinc/etc/conf.d/vsmagent.hconf there is no entry in agent\_hostname=

I agree the dns split configuration is apparently the solution OR my guess, not sure about this, maybe I need to configure a linux route rule for traffic which comes from 192.168.1. to 192.168.0. where the vsm server and agent are located such that they also reply and use the correct network 192.168.0. for clients of second network.

I would be very happy if you have further suggestions and I am looking forward to your reply.

Do you need further information?

Best Regards  
Juli

---

<div class="post-metadata">

**Author:** ![aaron](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/aaron/32/13_2.png) [@aaron](https://community.thinlinc.com/u/aaron)\
**Post date:** [31 March 2021 17:20 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/4 "2021-03-31T17:20:16Z")

</div>

@gwagon

If `agent_hostname` is empty, it will default to the IP address of the primary network interface.

There are probably a number of ways you could configure your network to achieve what you’re after, however I suspect the easiest way is to run ThinLinc in cluster mode, with multiple agents to spread the load across.

---

<div class="post-metadata">

**Author:** ![pewo](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/pewo/32/46_2.png) [@pewo](https://community.thinlinc.com/u/pewo)\
**Post date:** [15 April 2021 17:23 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/5 "2021-04-15T17:23:16Z")

</div>

I’m not sure how a cluster configuration would help in this case ?  
The split DNS or static routes on the client should absolutely work. The split DNS is of course the best way to handle this, if possible.  
The static route options on all 192.168.1.0 clients also works, but is not that nice.  
You probably could assign static host routes via DHCP.

---

<div class="post-metadata">

**Author:** ![gwagon](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@gwagon](https://community.thinlinc.com/u/gwagon)\
**Post date:** [12 May 2021 14:44 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/6 "2021-05-12T14:44:25Z")

</div>

Hello together,

I am interested with dns split or static route solution.

What for example do I have to configurate at the ububtu server for static route solutions?

Do I need a separate DNS Server for the dns split solution?

What are the steps for both solutions?

King Regards  
Juli

---

<div class="post-metadata">

**Author:** ![pewo](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/pewo/32/46_2.png) [@pewo](https://community.thinlinc.com/u/pewo)\
**Post date:** [13 May 2021 09:35 UTC](https://community.thinlinc.com/t/configured-thinlinc-server-but-new-installed-second-network-card-no-access/138/7 "2021-05-13T09:35:35Z")

</div>

If the thinlinc server requires you to connect to 192.168.1.1  
A static host route could solve the problem. This is not a scalable solution but might work for you.  
In this setup i don’t think you need to enable IP forwarding on the thinlinc server.

 ![iproute](https://europe1.discourse-cdn.com/flex005/uploads/thinlinc/original/1X/61558a6f8b07d620b7ea4cfbcd11def5cae9d61c.png)

A better way is to setup split DNS. The short version is that if your thinlinc servers is named “thinlinc”. Clients on 192.168.1.0 network should resolve “thinlinc” to 192.168.1.1 and the clients on the 192.168.2.0 network should resolve thinlinc to 192.168.2.1. This can be done in a single DNS server. Google “split dns”

> **[Split-horizon DNS](https://en.wikipedia.org/wiki/Split-horizon_DNS)**
>
> In computer networking, split-horizon DNS (also known as split-view DNS, split-brain DNS, or split DNS) is the facility of a Domain Name System (DNS) implementation to provide different sets of DNS information, usually selected by the source address of the DNS request.
> This facility can provide a mechanism for security and privacy management by logical or physical separation of DNS information for network-internal access (within an administrative domain, e.g., company) and access from an unsecur...
