Elastic Agent (Defender) – Public + On-Prem Deployment Question

Elastic Stack Elastic Agent
1

My goal is to deploy the Elastic Agent with the Defender integration as an XDR solution on our clients and forward all security alerts to our on-prem SIEM. Fleet and the rest of the Elastic components are reachable from the office network and through VPN.

The issue: employees are allowed to use their notebooks privately and we have a very flexible home-office policy. Not all work-related resources require a VPN connection.

My question:
Is it possible to configure the Elastic Agent so that it sends data to the internal ingest nodes when the device is on the corporate network, and automatically switches to a public log receiver when it is outside the company network or not connected to VPN?

1 Like
2

Hello and welcome,

You can configure multiple hosts in an output, but the agent will use all of them, so you may have cases where the Agent is on the private network but it is sending logs using the public endpoint.

They would also need to have access to Fleet when not on the private network/VPN, not just the endpoint to send logs.

2 Likes
3

Hello,

We’re facing a similar challenge and I’m trying to validate the best architecture for roaming endpoints.

In our case, some customer laptops are frequently off-VPN. When that happens the Elastic Agent can no longer reach the internal Fleet Server, so the agent stays in “offline” state until VPN comes back. Policy updates, status reporting and response actions are blocked during that period, even though Elastic Defend continues to enforce the last known policy.

One approach we’re evaluating is to run two Fleet Servers in the same Fleet:

Fleet Server A inside the customer network (for internal devices).

Fleet Server B exposed publicly through a hardened Proxy endpoint (for roaming laptops).

Both Fleet Servers would be connected to the same ES/Kibana backend, so the agent only belongs to one Fleet and one policy. Laptops would use multiple Fleet Server hosts for failover, so the agent automatically switches to the public Fleet Server when the internal one is unreachable.

This avoids re-enrollment and stays within a supported topology, but still ensures that roaming devices can check in and receive policy updates without requiring a VPN connection.

Before we move forward with this design:

Has anyone here deployed Fleet in a hybrid “internal + public Fleet Server” model for roaming endpoints, and did you encounter any issues with stability, upgrades, or agent behavior when switching between both endpoints?

Community insight from real-world deployments would be very helpful.

1 Like
4

The agent will switch between URLs configured for the same Fleet Server, they do not switch to different Fleet Servers.

So, the Fleet Server for the roaming laptops will have a public URL, if you want your agents to access this Fleet Server using your internal network when they are connected to the VPN, this same Fleet Server also needs to be accessible by a internal URL, and even in this way the agent may connect to the public URL, unless you block it when on the VPN to force them to use the internal URL.

I had this on my previous on-premises Cluster, with only one Fleet Server, this fleet server was configured with 2 hosts, one with a public URL and another one with a private URL, the Fleet Server was exposed to the internet behind a controlled load balancer were we blocked some sources.

But how are you doing with the ingestion? How is your cluster exposed? Both Fleet and the data output would need to be available outside the VPN.

3 Likes
5

Thanks a lot for your answer @leandrojmp

The agent will switch between URLs configured for the same Fleet Server, they do not switch to different Fleet Servers.

That’s what I meant actually, it’s one Fleet Server with 2 hosts, each with a different url, a public and a private.

So as it seems you already did this, good to know and again, thank you very much for your valuable feedback.

For the data output, we can also add a second url right?

6

Yeah, but keep in mind that you do not control which URL will be used if the agent can connect to both, so you may have cases where the host is inside the VPN, but sending data to the external URL.

7

Yeah, but keep in mind that you do not control which URL will be used if the agent can connect to both, so you may have cases where the host is inside the VPN, but sending data to the external URL.

I see, it would be nice if Elastic would provide a supported solution for this kind of problem so that it always prioritises the first / intenral url for example.

8

See Feature Request: Deterministic Priority for Internal Fleet Server URL and Elasticsearch Output URL · Issue #6018 · elastic/fleet-server · GitHub

2 Likes