Beacon setup with a secured LAN area

[E23008]

Hi Community a question We have a secured LAN area with only a one-way communication into our normal LAN area and not the other way around when we are talking FLEXERA. FNMS agent installed at server level inside this area as well. A Beacon server can be installed in this secured area but without the normal settings/communication to/from the Admin. Beacon, all as we from here can manages the agent's at server level. All changes have to be manages’ from inside the secured LAN area through a jump host setup. Does someone who have some ideas or already have a setup running?

[ChrisG]

If I'm understanding your scenario right, I understand that a beacon in the secured LAN area would be able to initiate a connection in to the normal LAN area where the admin server is. In this case you should be fine: a parent admin server/beacon (in the normal LAN area) does not have any need to initiate any network connections to child beacons (in the secured LAN area).

[adrian_ritz]

Hi,

Sorry to jump in your topic, but I'm in the same situation, I have some secured LAN where the communication is allowed only from Secure LAN -> Normal LAN where the admin servers are. I was thinking to implement a ZTI solution using only the core of the agent, and scripting command to upload inventory via https to a beacon in normal LAN. But this solution have some limitation, like the agent will be unmanaged, and no automatic update of the agent will take place with the new version update. My question to @ChrisG  is: do the normal agent  (I mean the one that is managed by admin servers) need both way communication or only from secure LAN -> normal LAN is allowed?

[ChrisG]

Communication during regular agent and beacon operations is always one way, from "child" (agent or beacon) to "parent" (beacon):

• Each agent initiates HTTP(S) connections to beacons to retrieve (GET) configuration details and upload (PUT) data.
• Each beacon initiates HTTP(S) connections to its parent to retrieve (GET) configuration details and upload (PUT) data.

@adrian_ritz - in your scenario, you could have:

1. A beacon in the secure LAN that initiates connections to its parent in the normal LAN.
2. Agents configured and running normally on devices in the secure LAN that initiate connections to the beacon in the secure LAN (or even to a beacon in the normal LAN if you didn't want a beacon in the secure LAN).

There is nothing in the scenario you have described that would require or benefit from the use of a ZTI approach.

[adrian_ritz]

Hi Chris,

Thank you for your quick reply, will take this info to security team.

[mfranz]

If it was the other way around and the child beacon could not talk to its parent beacon, I think all communication is file based. What I could imagine:

• Create a script, cmd or PowerShell on the parent beacon
• Have it mount a network drive "down" to the child beacon.
• PUSH updated configs to the child beacon
• PULL inventory and status files from the child beacon
• Unmount the network drive

[adrian_ritz]

Yes, I had such a case, with a DMZ zone for one of our customer, and the communication is allowed only from lan => DMZ zone. I used BITS protocol and powershell to transfer data. Installed the ZTI version of the agent with the option to upload to a file share but you can also install a beacon (stand alone beacon) , on the beacon create a powershell script that will generate a control file, as we need know which file we gather from beacon server. In the central network create other powershell script that will pull the control file, process it and transfer the .ndi files in the incoming folder according to list that is in the control file. As I used the ZTI solution, I didn't need to copy beacon control files and stuff like this. The limitation is that when you upgrade the agent you need manually to do this. I know that this is not a standard solution but at least it worked.

[JeffVoss]

I have multiple different variations of this type of configuration.

Send me a direct message since most security departments get nervous about the specifics of how to move in and out of a secure DMZ.