Keber Flores's picture

Hi all,

I've been trying to figure out how to solve this without success, maybe I'm missing something.

I have a turnkey virtual appliance with wordpress as an intranet since a couple of years, we can access it on the local network and through a VPN connection. I've recently deployed two more appliances, OTRS (finally installed osticket over) and redmine for ticketing and project management, but I can't access the last two through VPN.

All three are in same local network, so it shouldn't be our firewall. While on VPN I can reach other physical and virtual machines, wordpress one mentioned above included, but can't reach these two other turnkey appliances.


Any hints to start troubleshooting?

Jeremy Davis's picture

If you can't reach them via IP address, then I'm almost certain that it's something to do with your network config such as routing.

If you can reach them via IP, but not via domain (assuming you have that set up) then it's likely a DNS issue (possibly your VPN clients getting the DNS info from the internet, rather than your internal DNS server).

OTTOMH, neither of the other appliances you note do anything substantially different to WordPress.

If none of that helps, please provide more details on how it's all set up, and how your networking is configured. Info like how you access the servers (i.e. IP or FQDN) how the routing is configured (e.g. is it NATed? Are you using forwarded requests?) etc would likely be useful in helping to troubleshoot.

Jeremy Davis's picture

Assuming that the v16.x TKL appliances are using the static IP which you think they are, and you can't connect to them, then it's a networking issue of sort. Either the v16.x appliances do not have their networking configured correctly, or the network routing set up you have is not routing to the desired IP.

Out of interest, have you tried pinging back the other way (i.e. from the TurnKey app)? If you trying pinging other machines on the network from the new TurnKey VMs, that might at least whittle down possibilities.

Comparing the configured network routes for the working and non-working TKL servers might give some insight? Also checking the routing info on the PC that you're trying to connect to might also be useful? Armed with the routing info of your local PC, you could check that the working and non-working IPs are on the subnet via one of many online tools (e.g. try googling something like "tool to check if ip is within subnet").

If you can afford to shut down one of the computers (on the same network as the new TKL VMs) that you can currently successfully connect to, you could try this:

Confirm access to the currently working machine and it's IP address, then shut it down. Reconfigure a TurnKey v16.x VM to use that same IP (i.e. the machine you just shut down).

If you can now connect to the TurnKey server, then the issue is with your wider network, likely the VPN routing rules (the non-working TurnKey server IP(s) are likely not on the same subnet). If you still can't connect to the TurnKey VM, then it's on the TurnKey VM end. It could be the VM network config (e.g. ideally should be "bridged"). Or it could potentially be a range of things on the TurnKey end.

If it seems like it might be a routing issue, you could further confirm this with the same machine we stopped for the above test. If you restart that computer (i.e. the originally contactable machine) and manually set that to have the same IP as the non-working TKL server(s). If you can't connect via that same IP, that fully confirms that it's your broader network config.

Jeremy Davis's picture

Glad you worked it out and thanks for posting back. Thanks too for your kind words... :)

Add new comment