Laptops Not Connected To Network

[jeff_ziegler]

We have a standard network configuration, with a Core and a DMZ. All of the internal laptops connect to the Core when they are in the office or use VPN. However, when working from home many do not need to connect via VPN and that leaves the agents we plan to deploy out in the wild with no place to upload the daily inventory. Given that some of these may very well be off the Core network for months, we need a more durable solution. Has anyone created a successful architecture for this scenario? I have plenty of thoughts, but I would rather follow a proven pattern than risk an unproven one.

In addition to just how to configure agents/beacons for upload, there is obviously a concern about security. How is this handled in your pattern?

[kclausen]

One solution for this scenario is to deploy a beacon within your DMZ that an agent not connected to your network/VPN can upload inventory to.

[jeff_ziegler]

That is a reasonable solution, though I would rather keep it to one beacon if possible. If there isn't a supportable way for one beacon to be referred to in two different ways, then a second beacon is the only DMZ based option. Has anyone set up a Beacon to be accessed in two different ways (if that makes any sense)?

[kclausen]

@jeff_ziegler - By default, each agent as part of its Policy Package gets information about All of your registered beacons so that a "fail over" scheme is available for an agent to upload inventory.  At the time of the inventory upload, the agent looks at the list of available beacons and attempts to determine which one is best to use based on IP Subnets and Domains.  If an upload to that beacon fails, the agent will then attempt an upload to the remaining beacons until a successful upload is made.

In the case of your scenario, when a laptop is on your network or on the VPN, it will be able to upload to the beacon installed within your network.  When a laptop is not on the network, the upload to your internal beacon will fail, and then the agent will attempt an upload to the beacon within your DNZ and that attempt should succeed.

[jeff_ziegler]

My main question isn't about the agent, but the beacons. The agents will have a different problem. What I would like to see is the DMZ beacon be able to answer both DMZ servers as well as the external laptops. The problem is that would mean that the DMZ beacon would need to be referred to in two different ways (an internal IP and an external IP). This is really the primary question. Otherwise, I would likely need to set up a second DMZ beacon. I would rather avoid the overhead of another operational component, but I am not thinking there is a way around it. So the question is, really, has someone with this situation implemented something other than this?

As for the agents, typically I don't need a fail over scheme (until now). Core servers can only report to the Core beacon. DMZ Servers can only report to the DMZ Server. You are right, the laptops should primarily report to the Core beacon, then default to the DMZ beacon by the external IP (or the second DMZ beacon if I can't get the first one to work the way I would like), but I want it in that order. I don't really need a priority or selector algorithm to determine the order of beacons each agent should attempt.

[mfranz]

Hi Jeff,

Referring to the same Beacon in different ways (IPs) shouldn't be an issue from IIS perspective.

For the agents to know both IPs, you can manually add "fake" entries to the Beacon_MT table. This data is used to update the agent's download and reporting locations. I have successfully tested this to distribute alternative Beacon aliases (or IPs) to agents.

Best regards,

Markward

[jeff_ziegler]

That is an on-prem solution? we are FNMS in the cloud.

[mfranz]

Hi,

Yeah, of course, on-prem only. I don't see many options for the cloud, other than multiple Beacons.

Best regards,

Markward

[Garth_Honey1]

Hi,

You may want to consider deploying a beacon to your DMZ and giving it a public CNAME record. You can publish a route to networked devices via your internal DNS. When devices go off network they can still upload their inventory to the same FQDN CNAME address as long as they have an internet connection. Doesn't even require a VPN.

You also wouldn't have to mess around with configuring separate beacons for on-net and off-net devices or a beacon heirachy for devices that operate on both. You just need to make sure your beacon is using IIS rather than the internal web server and apply and enforce encryption and any other security controls your company may require.

[jeff_ziegler]

This is a nice, practical solution. It keeps the configuration for the laptop static and simple to support. I am hoping to avoid standing up another beacon; and I confess, it makes me a bit itchy to send data from a core connected laptop to an externally exposed beacon via the internet. If there isn't a way to easily manage a solution that involves existing beacons, this is likely what we will run with. I appreciate the recommendation.