An idea. If this is off kilter, I hope someone will correct me.
Maybe look into installing a Jump Point on a device in the specific network where the computers cant connect to the internet - and then just allow that one computer internet access - or at least the bare minimum connection access to the appliance itself. That will enable you to jump in to those devices on that segmented network.
Hello @mrsoso - As @LayerZeroIssue said, it may be required to use a Jumpoint somewher on your network and set up JZPs.
However - one hing I’ve seen with a number of customers is when you use a Public DNS hostname on the appliance which the Jump Clients will need to get back to. For instance, you could be using ‘support.example.com’ as a public DNS Hostname - which means your Jump Clients will need to reach AT MINIMUM your perimeter firewall in order to connect in. If you are blocking this, then that’s what you are seeing. If you switch to an internal only DNS name, like, ‘support.example.intra’ or such, and it is only routable inside your own network, I expect this to work.
What you can do, is run a TraceRoute or NSLookup on your current appliances DNS Hostname and see what your get back - is it an internal or external/public IP?
I appreciate the quick responses. So, each of these locked down PCs are able to connect to select resources on the LAN including the DMZ where our Bomgar server exists. We explicitly allow access to our Bomgar server via access list that permits any to the IP below. The DNS record for our server in the DMZ resolves to:
Name: bomgar.companyname.com
Address: 10.99.0.33
External PCs resolve that name to a public accessible IP address that I can’t put in here. The DNS name is exactly the same. It’s just if you’re connected outside of our network, you’ll get the public IP and if you’re inside our network, you’ll get the inside private IP address.
There has to be some sort of “check in” to the internet somewhere at Beyond Trust that all of our PCs need in order to report to our Bomgar server as “being alive and reachable”. I’d like to find a way to manually override that on the Bomgar server.
HI Mrsoso,
There are requirements.
- reachability to the bomgar device from clients.
- out bound port 80/443 from the client.
- DNS resolution from the client to the bomgar server.
- same version of client with the bomgar server.
and it should work.
Regards,
Sonam
I appreciate the quick responses. So, each of these locked down PCs are able to connect to select resources on the LAN including the DMZ where our Bomgar server exists. We explicitly allow access to our Bomgar server via access list that permits any to the IP below. The DNS record for our server in the DMZ resolves to:
Name: bomgar.companyname.com
Address: 10.99.0.33
External PCs resolve that name to a public accessible IP address that I can’t put in here. The DNS name is exactly the same. It’s just if you’re connected outside of our network, you’ll get the public IP and if you’re inside our network, you’ll get the inside private IP address.
There has to be some sort of “check in” to the internet somewhere at Beyond Trust that all of our PCs need in order to report to our Bomgar server as “being alive and reachable”. I’d like to find a way to manually override that on the Bomgar server.
Hello @mrsoso - I can confirm, none of our SRA software requires any sort of ‘internet check-in’ in order to function. The systems are designed to be able to used in fully isolated/air-gapped enviroments. The only connection the Jump Clients are concerned about are being able to connect back to their assigned appliance via DNS over TLS/SSL.
If your Jump Clients are not connecting in, then it is very likely there network configuration fault somwhere there. Hence our ask for DNS testing.
I appreciate the responses. I guess I’ll try running more tests. I may need to just open a case...
This is what I found out that I did not know regarding the dataflow.
When a support user running the Representative Console clicks the button to jump, it brings up a “local” jump. That’s the only option we see in our console. The user types the name of the PC. That connection is setup directly between the support users’ PC and the remote PC being supported. The connection is not proxied or “running through” the Bomgar server.
If someone pins the PC and then the support user selects that PC out of the listing of PCs, then the connection is proxied through the Bomgar server.
Maybe this isn’t the correct way to do things. I don’t know. I wasn’t part of the install. For now, we pinned all of the computers that are locked down via a Cisco ACL and permitted the Bomgar server to get to those PCs. When the support user selects the PC out of the list, everything works fine.
The other option now may be to create the Jumpoint inside our network instead of in the DMZ but I would need to research how to set things. I’m wondering if the initial “remote jump” was set up and pinned if that setting would be sticky in the same way as described above but “proxied” through the jumpoint inside.
Thanks all.
Hello @mrsoso - when you are describing ‘pinned’ session, what this does is install a Jump Client. These have a direct connection back to the appliance they create, and this is what is used for sessions. You can deploy these before any session however, through /login > Jump > Jump Client Wizard. And, on the other hand, Local Jump is a different method of running a session which - as you say - requires an active link between the Rep Console and the endpoint.
There is no ‘wrong way’ to run sessions or deploy these clients really, there is only the way which works for you. Pinning a session while running it is a valid way of deploying Jump Clients, as is creating an installer and using a Mass-Deployment tool to get them deployed. Whichever way works for your enviroment, then that is fine.
