Daisy Chaining Gateways for access into different network segments

Hello @Yoffstr

There is no plan for Gateway Daisy Chaining as-is, but I think we’ll have a solution for the problem you are describing: the Agent Tunnel feature.

I’m talking about it in this thread: https://forum.devolutions.net/topics/52725/reverse-proxy-for-gateway-agents?message=226688#226688

With this feature, you:

• Place a Devolutions Gateway, exposed to the internet in the DMZ
• Place a Devolutions Agent on the DMZ/internal edge

DVLS will route through the Devolutions Gateway (DMZ), and the Devolutions Gateway will route through the Devolutions Agent (DMZ/internal edge), but with a call home model such that you just need to allow outbound connections from the Devolutions Agent to the Devolutions Gateway. You don’t need to allow inbound connections.

I believe that would be the most hardened network setup you could imagine as of today.

Is it addressing your concern?

Best regards,

Hi Benoit,

Yes, this is perfect and addresses my concern, as i didnt want to expose a gateway on the DMZ/internal edge to the internet, in order to access internal servers.

Kind regards

Yoffstr

following my last post, how do we best implement this setup?

HI @Benoit Cortier,

After reviewing the conversation witihin the linked forum thread which is more centered around reverse proxy, which we are not wanting to achieve - but would be nice) and tinkering around with the gateway farms we have deployed in test. i have made a couple of illustrations on how we would want to utilise gateway farms and how we would want to daisy chain them effectively:

Accessing servers - External Vendor:

External Vendor is able to remote in and connect via the public facing gateway in the DMZ. If the external vendor needs to access a server in the DMZ, the DMZ gateway farm will route to the server or devicee and then hold any session recordings required. If the External vendor needs to access a internal server or device instead, it then routes it through too the internal gateway farm (for high avilability) to connect up.


Accessing servers - Corporate:

Corporate laptops (either on premise or VPN) access servers via the internal gateway farm (session recording if required) to access the internal servers or devices. If they need to connect to a server ro deevice ein thee DMZ, then the internal gateway farm routes through the dmz gateeway farm, to connect up to the server or device required.


looking forward to heearing the teams thoughts.

Kind regards

Hi @Yoffstr

Thank you for the feedback. Graphs made this easy to understand.

I agree that the Agent Tunnel solution does not really match the original symmetric gateway-chaining design.

I’m thinking that a more practical compromise could be:

• An internal Devolutions Gateway for corporate access.
• A DMZ Gateway with an Agent Tunnel for external access to internal resources.
• Recordings stored on the Gateway handling the session, using the existing “same as session” or custom recording Gateway settings where appropriate.

True daisy-chaining would be considerably more complex because each Gateway would need to securely forward session traffic, authorization context, auditing, recording, failure handling, and potentially farm load balancing across another independently managed Gateway. That would introduce significant architectural and operational complexity, so honestly it is unlikely to be implemented in the near term.

This alternative is still asymmetric and relatively advanced, but it avoids trying to chain two Gateway Farms together. The main remaining challenge would be selecting the appropriate Gateway based on whether the user is internal or external, which may require separate entries or configuration scopes… Maybe we could facilitate this by introducing policy-based Gateway selection. For example: choosing the Gateway based on user group, access method, source context, or target zone. That would reduce duplicated entries and make this deployment pattern feel much more intentional.

How does that sound?

Best regards,

Hi @Benoit Cortier,

Policy based does sound good. However this is more about the routing of traffic between the two gateway farms.

Another idea is that you could adjust the gateway dataset config, so that we can essentially add in routes. for example - if wanting to get too 10.100.10.0/25 - pass traffic to gateway farm internal. Also make both gateway farms part of a super farm or something, so that they are aware of each other and what IP ranges each farm has access too?

With regards to your question about detecing internal vs external (this is if they dont have a VPN). This is how I have seen other companies achieve this:

1. We list down all the LAN IP ranges (for example 192.168.1.0/24)
2. Have a ping-able internal FQDN host, that only the LAN networks can resolve.
3. If on external network, then default to Public FQDN to access gateway.

This will then give you a two different variables run a check against, for example:

If host is on LAN IP Range and able to ping INTERNAL HOST = on internal network

If host is on LAN IP Range and NOT able to ping INTERNAL HOST = external network (as network range might be used at another location). -> go to public FQDN gateway.

If host is NOT on LAN IP Range and NOT able to ping INTERNAL HOST = external network -> go to public FQDN gateway.

Kind regards

Hi @Benoit Cortier,

Policy based does sound good. However this is more about the routing of traffic between the two gateway farms.

Another idea is that you could adjust the gateway dataset config, so that we can essentially add in routes. for example - if wanting to get too 10.100.10.0/25 - pass traffic to gateway farm internal. Also make both gateway farms part of a super farm or something, so that they are aware of each other and what IP ranges each farm has access too?

With regards to your question about detecing internal vs external (this is if they dont have a VPN). This is how I have seen other companies achieve this:

1. We list down all the LAN IP ranges (for example 192.168.1.0/24)
2. Have a ping-able internal FQDN host, that only the LAN networks can resolve.
3. If on external network, then default to Public FQDN to access gateway.

This will then give you a two different variables run a check against, for example:

If host is on LAN IP Range and able to ping INTERNAL HOST = on internal network

If host is on LAN IP Range and NOT able to ping INTERNAL HOST = external network (as network range might be used at another location). -> go to public FQDN gateway.

If host is NOT on LAN IP Range and NOT able to ping INTERNAL HOST = external network -> go to public FQDN gateway.

Kind regards

Hi @Benoit Cortier,

Following on from my last post. the inter-routing between the two gateways would need to be secured and minimal port eexposeure. (for example - inter routing done on a SSL port, maybe use a dedicated port?).

Hi @Yoffstr

I want to validate the actual requirements once more, because the proposed “super farm” is a specific implementation rather than necessarily the underlying need.

As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure.

Gateway federation is an interesting concept: effectively, a peer network of farms where selecting the federation provides access to anything it can route to. However, implementing it would require substantial work around trust, route exchange, loop prevention, authorization, auditing, recording, failover, and compatibility. It would solve valid scenarios, but many of them can already be addressed using simpler mechanisms. Unless we identify requirements that specifically require both Gateway Farms to participate in the session, it is unlikely to be implemented in the foreseeable future. Keeping the request open still makes sense, particularly if broader demand or additional use cases emerge.

The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner.

Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!

Looking forward to your reply.

Best regards,

Hi @Yoffstr

I want to validate the actual requirements once more, because the proposed “super farm” is a specific implementation rather than necessarily the underlying need.

As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure.

Gateway federation is an interesting concept: effectively, a peer network of farms where selecting the federation provides access to anything it can route to. However, implementing it would require substantial work around trust, route exchange, loop prevention, authorization, auditing, recording, failover, and compatibility. It would solve valid scenarios, but many of them can already be addressed using simpler mechanisms. Unless we identify requirements that specifically require both Gateway Farms to participate in the session, it is unlikely to be implemented in the foreseeable future. Keeping the request open still makes sense, particularly if broader demand or additional use cases emerge.

The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner.

Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!

Looking forward to your reply.

Best regards,

Hi @Benoit Cortier,

Sorry i probably went abit overboard with my suggestions.

As per your post: "As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure."

Your are correct, this is the scope.

"The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner."

If you believe this simplified approach will work, happy to try it out.

The gateways by recommendation, is to have agents on them for auto updating, so i can guess they can be utilised for the tunnels. The only thing I am not sure is, for utilising the agent tunnels, could they be utilised in a active passive setup for high availiabilty?

"Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!"

All good, happy to help.

Hi @Yoffstr

I want to validate the actual requirements once more, because the proposed “super farm” is a specific implementation rather than necessarily the underlying need.

As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure.

Gateway federation is an interesting concept: effectively, a peer network of farms where selecting the federation provides access to anything it can route to. However, implementing it would require substantial work around trust, route exchange, loop prevention, authorization, auditing, recording, failover, and compatibility. It would solve valid scenarios, but many of them can already be addressed using simpler mechanisms. Unless we identify requirements that specifically require both Gateway Farms to participate in the session, it is unlikely to be implemented in the foreseeable future. Keeping the request open still makes sense, particularly if broader demand or additional use cases emerge.

The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner.

Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!

Looking forward to your reply.

Best regards,

Hi @Benoit Cortier,

Sorry i probably went abit overboard with my suggestions.
As per your post: "As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure."

Your are correct, this is the scope.
"The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner."

If you believe this simplified approach will work, happy to try it out.

The gateways by recommendation, is to have agents on them for auto updating, so i can guess they can be utilised for the tunnels. The only thing I am not sure is, for utilising the agent tunnels, could they be utilised in a active passive setup for high availiabilty?
"Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!"

All good, happy to help.

hi @Benoit Cortier,

sorry one thing i forgot to mention in the scope, is the traversal needs to be both ways.

For example: clients in internal network, connect to internal gateway, that connects to agent in DMZ, to connect to servers in DMZ. While also external clients, connect to the gateway in the dmz, gateway connects to agents in internal network, to connect to servers in internal network.

kind regards

Hi again,

Thank you for confirming!

Following up on my own post. The diagrams you shared made your setup much easier to understand, so it seemed worth doing the same, and here it is:


One refinement on the probe. It can be as narrow as "can I reach the internal Gateway" rather than an internal-only FQDN, because a split-horizon record can resolve over a VPN that still cannot route to the farm. Testing the Gateway itself is both simpler and more accurate.

The only thing I am not sure is, for utilising the agent tunnels, could they be utilised in a active passive setup for high availiabilty?

Honestly, high availability is a gap: on the "no" branch the internal next hop is a single Agent rather than a farm, so it has no redundancy today.
That is the main thing I would want to address before calling this a complete answer to your diagrams.
Fortunately, agent redundancy is a very reasonable feature we could add to Agent tunneling, and we are actually already thinking about it.

Best regards,

sorry one thing i forgot to mention in the scope, is the traversal needs to be both ways.

For example: clients in internal network, connect to internal gateway, that connects to agent in DMZ, to connect to servers in DMZ. While also external clients, connect to the gateway in the dmz, gateway connects to agents in internal network, to connect to servers in internal network.

kind regards

Oops, I missed this message when I sent the previous one.

So I assumed that the Gateway in DMZ was accessible to clients in the internal network, but if that’s not the case, we could imagine exactly what you just said!

The caveat here compared to federations is that you, as an network administrator, will need to configure more components: "two Gateway farms in a single federation" vs "two Gateway farms and two Agent farms" + configure the selection policy (e.g.: can I reach DMZ Farm? Can I reach internal Farm?) for each relevant entries.

EDIT: Noting that you don’t need more machines since you can still have both a Gateway and an Agent per node. (Agent that you may already have installed for the updater module anyway.)

We’ll have to think about how to make this easy to configure.

Best regards,

sorry one thing i forgot to mention in the scope, is the traversal needs to be both ways.

For example: clients in internal network, connect to internal gateway, that connects to agent in DMZ, to connect to servers in DMZ. While also external clients, connect to the gateway in the dmz, gateway connects to agents in internal network, to connect to servers in internal network.

kind regards

Oops, I missed this message when I sent the previous one.

So I assumed that the Gateway in DMZ was accessible to clients in the internal network, but if that’s not the case, we could imagine exactly what you just said!

The caveat here compared to federations is that you, as an network administrator, will need to configure more components: "two Gateway farms in a single federation" vs "two Gateway farms and two Agent farms" + configure the selection policy (e.g.: can I reach DMZ Farm? Can I reach internal Farm?) for each relevant entries.

EDIT: Noting that you don’t need more machines since you can still have both a Gateway and an Agent per node. (Agent that you may already have installed for the updater module anyway.)

We’ll have to think about how to make this easy to configure.

Best regards,

Hi @Benoit Cortier,

As you said: "So I assumed that the Gateway in DMZ was accessible to clients in the internal network, but if that’s not the case, we could imagine exactly what you just said!"

No the client network cant access the DMZ gateways. Essentially following the zero trust model, we would want to poke as minimal holes in the internal network / dmz boundary to stop any risks or exposure, and hinder any lateral movment if something was to occur.

Hence why i suggested either a different port to be use from the standard/common ports for the communication between the two gateways or in this case gateway to agent tunnels.

kind regards