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
